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Abstract 


In  recent  years,  simulation  has  become  a  very  important  tool  in 
education,  research  and  development,  and  training.  With  the  advent  of 
more  complex  and  more  'pensive  navigation  systems,  simulation  has 
proven  to  be  a  cost-effective  and  reliable  way  to  enhance  the  learning 
environment . 

This  thesis  develops  a  simulation  that  emulates  a  Litton  LN-94 
INS.  Real-time  simulation  is  achieved  for  a  stationary  navigation  case 
and  a  straight-and-level  flight  trajectory  are  provided  to  exercise  the 
simulation  dynamics.  The  user  interface  is  simple  and  requires  little 
previous  knowledge  to  operate.  The  communication  link  with  the  MILSTD 
1553B  bus  provides  a  realistic  environment  in  which  to  collect  and 
analyze  data. 

The  simulation  is  processed  on  an  80386  IBM  compatible  personal 
computer.  A  23 -state  INS  error  model  is  implemented  and  integration  is 
performed  by  a  fifth-order  Kutta-Merson  routine.  The  simulation  is 
interfaced  to  a  plotting  routine  and  data  collection,  both  data  type  and 
rate,  is  controlled  through  the  user  interface.  Simulation  status  and 
output  is  viewed  from  the  simulation  screen  or  on  the  MILSTD  1353  bus 
monitor . 

The  simulation  is  programmed  in  C  programming  language.  Program 
development  is  discussed  and  flow  charts  of  the  major  modules  provided. 
The  simulation  validation  process  is  outlined  and  results  are  presented. 
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DEVELOPMENT  OF  A 

PERSONAL  COMPUTER  SIMULATION  PROGRAM 
OF  THE  LN-94  INERTIAL  NAVIGATION  SYSTEM 


I-  Introduction 

This  thesis  develops  and  implements  a  high  fidelity  LN-94  Inertial 
Navigation  System  simulation  program.  The  simulation  emulates  an  LN-94 
23 -state  truth  model  and  operates  under  MS  DOS  on  an  IBM  compatible  386 
PC.  The  simulation  is  capable  of  two-way  communication  on  a  MILSTD 
1553B  communication  bus,  and  data  input  and  output  is  controlled  by  a 
1553B  bus  controller.  The  simulation  offers  the  user  a  number  of 
options  in  vehicle  trajectory,  state  storage  and  plotting,  and  data 
storage.  Vehicle  trajectory  information  is  provided  to  the  simulation 
from  an  independent  trajectory  development  program  [15]. 

This  chapter  provides  the  reader  with  background  information  and 
research  goals  are  presented  in  detail.  The  research  approach  is 
discussed  and  limitations  in  the  scope  of  the  research  are  indicated. 

An  overview  of  the  remaining  chapters  of  the  thesis  is  presented  at  the 
end  of  the  chapter. 

2 . 2  Background 

The  concept  of  simulation  has  proven  to  be  a  valuable  aid  in 
research,  development,  testing,  and  training.  With  the  advances  in 
computer  technology,  simulation  becomes  a  more  attractive  approach  since 
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more  complex  problems  can  be  simulated  in  real  time  and  with  increased 
fidelity.  In  stride  with  these  advances,  avionics  equipment  has  become 
much  more  complex,  more  expensive,  and  requires  specialized  equipment  to 
support  its  operation.  In  addition,  avionics  equipment  is  difficult  to 
obtain  and  very  expensive  to  repair. 

A  simulation  developed  to  work  in  concert  with  actual  components 
can  support  education  and  research,  resulting  in  an  enhanced  research 
and  education  environment.  Such  a  simulation  must  be  capable  of 
operating  with  the  same  accuracy  and  exhibit  the  same  operating 
characteristics  as  the  original  equipment.  The  simulation  must  also  be 
capable  of  providing  information  to  the  user  in  the  same  format  as  that 
which  is  provided  by  the  actual  INS. 

A  situation  in  which  a  simulation  would  be  advantageous  is  the  Air 
Force  Institute  of  Technology's  Navigation  Laboratory.  This  laboratory 
environment  has  been  established  to  provide  hands-on  experience  and 
research  capability  for  graduate  students  analyzing  the  operation  of 
current  navigation  systems.  Specifically,  the  laboratory  operates  a 
Litton  LN-94  ring  laser  gyro  strapdown  inertial  navigation  system  (INS) , 
a  Litton  LN  39  gimballed  INS,  a  Rockwell-Collins  Phase  IIIA  Global 
Positioning  System  (GPS)  receiver,  and  several  personal  computer  systems 
to  facilitate  system  operations  [23].  All  systems  are  coupled  to  a 
MILSTD  1553B  communication  bus  which  is  controlled  by  a  PC-based 
software  package  and  interface  card  developed  by  Digital  Technology  Inc 
[13]  . 

The  laboratory  INS  systems  have  been  inoperable  at  various  times 
in  the  past,  which  has  led  to  some  delays  in  teaching  and  research. 
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This  problem  highlights  the  need  for  an  alternative.  A  simulation  that 
can  accurately  emulate  the  operation  of  these  systems  Is  one  solution. 

A  high  fidelity  simulation  of  the  LN-94  INS,  in  this  case,  can  provide 
the  necessary  navigation  information  and  performance  as  well  as  augment 
the  use  of  actual  components . 

1.2  Research  Objectives 

The  overall  objective  of  this  thesis  is  to  develop  a  high  fidelity 
PC-based  simulation  program  emulating  the  performance  of  the  LN-94  INS. 
The  program  development  begins  with  a  simulation  program  developed  by 
Intermetrics  Inc.  of  Huntington  Beach  CA  [1].  This  program  is  discussed 
in  some  detail  in  Section  2.2  of  Chapter  2.  Using  this  program  as  a 
starting  point,  the  following  sub- objectives  are  achieved  in  order  to 
meet  the  overall  thesis  objective: 

1.  Verify  both  the  level  of  detail  of  the  simulation  and  the 
accuracy  of  the  Intermetrics  program. 

2.  Identify  a  truth  model  for  the  LN-94  errors,  program  the 
model,  and  incorporate  it  into  the  simulation. 

3.  Select  and  program  a  high  accuracy  integration  routine  to 
propagate  the  truth  model  states. 

4.  Program  a  validated  random  number  generator  to  provide 
simulated  white  Gaussian  noise  to  the  stochastic  truth  model. 

5.  Develop  vehicle  trajectory  files  to  allow  a  number  of 
different  scenarios  for  the  simulation. 
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6.  Ensure  simulated  LN-94  information  provided  to  the  1553  data 
bus  is  in  the  same  format  as  the  information  provided  by  the 
actual  equipment. 

7.  Develop  and  implement  a  user  interface  to  provide  options  in 
trajectory,  data  storage,  and  plotting. 

8.  Validate  the  simulation  to  determine  the  level  of  fidelity. 

1 . 3  Research  Approach 

As  is  noted  in  Chapter  2,  Section  2.2,  the  Intermetrics  simulation 
in  its  original  form  is  extremely  limited  as  a  simulation  of  true  INS 
functions.  It  is  essentially  a  communications  shell  that  simulates 
Standard  Navigation  Unit  (SNU)  84-1  INS  message  traffic  based  on  the 
MILSTD  1553B  protocol  [4,22],  Simulated  navigation  performance  based  on 
spherical  earth  calculations  with  constant  vehicle  velocity  and  heading 
is  provided.  This  thesis  improves  the  capability  by  incorporating  a  23- 
state  LN-94  error  model  into  the  simulation.  The  model  emulates  the  LN- 
94  operating  characteristics  and  the  simulation  produces  MILSTD  1553B 
formatted  data.  The  simulation  is  validated  using  a  number  of 
trajectory  profiles. 

As  clarification,  the  SNU  84-1  is  a  USAF  document  which  issues 
design  guidelines  for  an  inertial  navigation  system  based  on  standard 
form,  fit,  and  function.  The  LN  specification  is  a  designator  for 
Litton  developed  systems. 

A  23-state  LN-94  error  model  is  used  in  an  effort  to  minimize  the 
computation  overhead  and  at  the  same  time  achieve  sufficient  accuracy  in 
the  simulation.  Two  other  alternatives  wer»  considered  but  deemed 
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unsuitable.  Those  included  use  of  the  full  93-state  model  and  a  39- 
state  model.  This  particular  version  of  the  LN-94  model  is  provided  as 
a  result  of  research  done  at  AFIT  by  Stacey  [26],  This  makes  the 
simulation  dedicated  to  an  LN-94  implementation.  However,  the  modular 
nature  of  the  program  makes  changing  the  truth  model  for  simulating 
another  INS  a  fairly  simple  programming  task. 

Numerical  integration  of  the  error  model  equations  simulates  the 
LN-94  error  values  as  a  function  of  time.  Numerical  accuracy  is 
important  as  error  values  are  very  small,  particularly  early  in  the 
navigation  cycle.  To  achieve  the  necessary  computation  accuracy,  the 
integration  routine  chosen  is  a  fifth-order  routine.  Double  precision 
programming  techniques  are  used  in  the  integration  routine. 

By  using  the  data  available  in  Britting  [8]  and  in  the  Litton 
Consolidated  Data  Requirements  List  (CDRL)  [17],  the  nine  basic 
navigation  error  states:  three  position  errors,  three  tilt  errors,  and 
three  velocity  errors,  can  be  compared  for  determining  the  simulation's 
accuracy.  In  addition,  a  comparison  with  the  actual  INS  in  static 
navigation  is  used  as  a  measure  of  fidelity.  The  simulated  results  must 
agree  in  magnitude  and  modal  character  with  the  actual  INS  data, 
demonstrating  that  the  error  model  and  integration  routine  are  valid. 

Trajectory  data  provide  the  simulation  with  the  true  path  of  the 
INS.  The  INS  truth  model  represents  the  error  behavior  of  the  INS.  If 
the  errors  are  summed  with  the  trajectory  information,  the  result  is  the 
simulated  navigation  solution  provided  by  the  INS. 

The  simulated  INS  information  is  processed  to  provide  real-time 
vehicle  information.  Program  computation  time  plays  a  critical  role  in 
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achieving  real-time  processing.  Care  is  taken  to  optimize  computation 
to  achieve  this  goal. 

Limiting  the  simulation  to  one  trajectory  would  severely  reduce 
the  functionality  of  the  simulation,  so  a  more  generalized  approach  is 
taken.  To  exercise  the  simulation,  three  trajectories  are  provided. 
These  trajectories  provide  sufficient  evaluation  of  the  simulation  and 
allow  different  vehicle  operating  environments.  The  flight  trajectories 
are  provided  in  the  form  of  files  on  the  host  computer  hard  disk  and  are 
selectable  from  the  user  keyboard.  The  static  navigation  is  coded  into 
the  program.  The  three  trajectories  are: 

1.  Static  navigation 

2.  Straight  and  level  with  constant  velocity  from  a  predetermined 

initial  position  and  heading 

3.  An  air-to-ground  fighter  profile  as  described  in  the  Litton 

CDRL  [17] . 

A  hybrid  program  of  PROFGEN  [2]  known  as  INERCA  [15]  is  used  to  generate 
the  trajectory  information.  INERCA  is  selected  based  on  its  user 
interface . 

The  LN-94  specification  that  dictates  the  communication  protocol 
is  the  Fighter  Navigation  Unit  (FNU)  85-1  Specification  [3].  To 
simulate  the  LN-94  properly,  the  information  provided  by  the  simulation 
to  the  1553B  communication  bus  must  satisfy  this  specification.  The 
Interroetrics  simulation  follows  the  SNU  84-1  specification.  The 
approach  here  is  to  change  the  input  and  output  specification  to  produce 
LN-94  type  information  in  accordance  with  FNU  85-1. 
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The  simulation  input 
longitude.  The  simulation 
Table  1.1.  The  simulation 
on  the  1553B  bus. 


consists  of  present  position  latitude  and 
output  is  limited  to  the  parameters  listed  in 
data  is  formatted  as  per  Appendix  A  for  use 


Table  1.1  Output  Parameters 


Parameter 

Output 

(FNU  85-1  Table  IV) 

pitch 

7 

roll 

8 

N-S  velocity 

10 

E-W  velocity 

11 

vertical  velocity 

12 

inertial  altitude 

13 

present  pos  lat 

14 

present  pos  long 

15 

platform  azimuth 

104 

wander  angle 

36 

N-S  acceleration 

16 

E-W  acceleration 

17 

vertical  acceleration 

18 

pitch  rate  (body) 

33 

roll  rate  (body) 

34 

yaw  rate  (body) 

35 

The  user  interface  for  any  program  is  critically  important  as  it 
normally  dictates  the  acceptance  of  a  program  and  the  extent  to  which  it 
is  used.  For  this  interface,  a  question  and  answer  approach  is  used  to 
interrogate  the  user.  The  user  keys  in  the  appropriate  responses  from 
the  keyboard.  All  options  are  selected  prior  to  executing  the 
simulation.  After  the  simulation  starts,  the  user  may  communicate  with 
the  simulation  by  keyboard  or  1553B  bus  commands. 
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To  assist  the  user  in  getting  the  most  information  out  of  the 
simulation,  the  following  options  are  programmed  into  the  simulation: 

1.  type  of  trajectory  to  use 

2.  whether  data  collection  is  required 

3.  time  interval  between  collection  points 

4.  what  data  to  collect  (ie.,  which  states  to  monitor) 

5.  duration  of  simulation 

The  validation  approach  for  the  overall  simulation  is  based  upon 
the  accuracy  criteria  contained  in  FNU  85-1.  By  comparison  of  the 
trajectory  data  with  the  data  that  is  provided  by  the  simulated  INS,  the 
performance  of  the  simulation  should  not  exceed  maximum  allowable 
limits.  Alignment  is  not  a  variable  condition  of  this  simulation,  so 
the  four  minute  normal  gyrocompass  alignment  criterion  shall  be  used. 
Fidelity  of  the  simulation  is  measured  by  the  ability  to  achieve  these 
conditions.  Exact  details  on  the  procedures  for  fidelity  measurement 
are  provided  in  Chapter  4,  Section  4.2.1. 

1.4  Thesis  Overview 

Including  this  introductory  chapter,  this  thesis  is  comprised  of 
five  chapters  and  ten  appendices.  Chapter  2  introduces  the  theory  that 
is  necessary  to  develop  the  simulation  program.  Chapter  3  provides 
insight  into  the  approaches  taken  in  developing  the  simulation  from  a 
programming  point  of  view.  Chapter  4  outlines  the  validation  process  of 
rhe  simulation.  This  includes  validation  of  the  23-state  model  and 
comparison  of  the  simulation  performance  with  actual  INS  data.  The 
final  chapter  restates  the  major  objectives  of  the  thesis  and  summarizes 
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to  what  degree  the  goals  have  been  met.  Validation  results  are 
summarized  and  recommendations  and  comments  for  future  development  are 
provided . 

The  appendices  provide  supporting  figures  and  tables,  a 
description  of  program  functions,  validation  results,  and  a  user's  guide 
for  the  simulation.  Appendices  are  listed  as  follows: 

Appendix  A:  FNU  85-1  Word  Formats 
Appendix  B:  LN-94  Truth  Model  Definition 
Appendix  C:  LN-94  Dynamics  and  Noise  Matrices 
Appendix  D:  Programming  Flow  Charts 
Appendix  E:  Program  Functions 
Appendix  F:  Simulation  Operator's  Manual 
Appendix  G:  Reduced  Order  Model  Validation  Results 
Appendix  H:  Simulation  Validation  Results  for  Static  Navigation 
Appendix  I:  Simulation  Validation  Results  for  Straight  and  Level 
Traj  ectory 

Appendix  J:  Error  Behavior  of  Simulated  Straight  and  Level 
Traj  ectory 
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II.  Theory 


As  discussed  in  the  Chapter  1,  the  primary  objective  of  this 
thesis  is  to  develop  a  high  fidelity  simulation  of  an  LN-94  INS.  The 
objectives  have  been  presented  and  the  research  approach  has  been 
outlined.  This  chapter  reviews  the  theory  that  is  required  to  develop 
the  simulation. 

Of  particular  importance  to  this  research  is  a  discussion  of  the 
theory  necessary  to  understand  the  operation  of  the  LN-94,  its  error 
model,  and  the  propagation  techniques  used.  An  outline  of  MILSTD  1553B 
principles  and  a  discussion  of  applicable  hardware  are  included.  The 
chapter  concludes  with  a  summary  of  the  software  necessary  to  conduct 
this  research  and  to  execute  the  simulation. 

2.1  1H-94  Inertial  Navigation  System 

The  INS  for  this  research  is  the  Litton  Systems  LN-94.  As  a 
matter  of  procedure,  the  term  LN-94  will  be  used  through  out  this  theory 
chapter  and  the  remainder  of  the  document.  This  is  noted  as  confusion 
may  arise  from  the  fact  that  the  Litton  CDRL  refers  to  an  LN-93. 
Operationally  the  two  configurations  are  identical.  The  different 
designation  lies  in  the  fact  that  the  LN-94  is  an  LN-93  that  is 
physically  reconfigured  for  use  in  the  F-15. 

The  LN-94  is  a  strapdown  inertial  system  using  three  single - 
degree-of-freedom  accelerometers  and  three  ring  laser  gyroscopic 
sensors.  Strapdown  refers  to  the  concept  that  there  is  no  moving  gimbal 
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structure.  There  is  no  angular  motion  of  components  with  respect  to  the 
vehicle,  and  the  body  frame  represents  the  mechanization  frame. 

As  is  implied  by  the  last  statement,  the  INS  implements  its 
operation  in  terms  of  reference  frames.  The  LN-94  frames  are  the 
accelerometer  a-frame,  gyro  g-frame,  the  sensor  s-frame,  the  body  b- 
frame,  the  platform  p- frame,  the  computer  c- frame,  and  the  true  t- frame. 
For  this  implementation,  the  body  frame,  the  sensor  frame,  and  the 
platform  frame  are  the  same.  The  computer  frame  is  the  frame  in  which 
the  INS  computations  are  done  and  the  true  frame  represents  the  actual 
navigation  frame. 

To  highlight  the  relationship  of  these  frames  to  each  other  a  look 
at  the  transformation  equations  is  appropriate.  All  INS  data  is 
computed  in  the  computer  frame  and  represents  the  INS -indicated  values. 
To  transform  gyro  and  accelerometer  data  into  the  true  frame  the 
following  transformations  are  used: 

ct~(%c*ci  (1) 

and 

Cm  *  C“  (2) 

where  C  is  the  direction  cosine  matrix  transforming  vectors  from  the 

lower  subscript  frame  to  the  upper  subscript  frame. 

Since  the  sensitive  axes  of  both  gyros  and  accelerometers  is 
nominally  aligned  with  the  body  axes,  except  for  uncalibrated 
installation  errors,  then  it  must  be  assumed  that  the  body  sensor 
transformation  is  equal  to  identity.  All  transformations  from  the 
sensor  frame  to  the  true  frame  can  then  be  achieved  using  the  body-to- 
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true-frame  transformation.  Refer  to  Section  2.1.1  for  a  description  of 
the  different  coordinate  frames. 

The  system  is  not  without  errors.  These  errors  are  represented  by 
misalignments  between  frames.  The  true  frame  is  offset  from  the 
computer  frame  by  an  error  vector,  68,  which  represents  the  computation 
errors  and  the  uncertainties  of  the  INS .  These  errors  propagate 
themselves  in  the  form  of  latitude,  longitude,  and  wander  angle  errors. 
The  true  frame  is  also  offset  from  the  platform  frame.  This  offset 
represents  the  physical  misalignment  in  the  gyros  and  accelerometers 
when  they  are  mounted  to  the  INS . 

The  accelerometers  provide  specific  force  measurements  experienced 
by  the  INS  and  the  gyros  provide  attitude  rate  measurements  due  to  body 
and  earth  rotations .  Accelerometer  and  gyro  triads  provide  these 
measurements  in  each  of  the  three  sensitive  axes.  This  information  is 
used  to  determine  position,  velocity,  and  attitude  of  the  INS.  A 
digital  computer  monitors  the  vehicle  attitude  based  on  gyro 
information.  From  this  information  the  computer  can  then  provide  the 
transformation  necessary  to  transform  the  specific  force  measurements 
into  the  computation  frame  [8].  As  mentioned  previously,  the  computer 
then  computes  the  transformation  into  the  true  frame  and  useful 
navigation  information  is  provided. 

The  LN-94  is  defined  as  a  local  level  wander  azimuth  mechanization 
[16],  This  means  that  the  vertical  axis  is  uncommanded  [8],  Only 
level  axes  are  commanded  and  the  wander  angle  represents  the  angle  about 
the  vertical  axis  between  north  and  the  wander  azimuth  y-axis.  By 
monitoring  this  angle,  the  INS  will  always  know  the  platform  attitude 
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but  the  reference  frames  will  be  skewed  by  the  wander  angle.  Since  the 
LN-94  is  a  strapdown  INS,  commanding  the  level  axes  is  a  software 
function.  This  implementation  is  particularly  useful  in  the  polar 
regions  as  the  vertical  axis  is  insensitive  to  azimuth  gyro  torquing 
uncertainties . 

2.1.1  Reference  Frames .  The  navigation  solution  is  normally 
expressed  in  terms  of  latitude,  longitude,  and  altitude;  better  known  as 
geographical  coordinates  or  simply  map  coordinates.  In  any  navigation 
system  it  is  often  more  useful  to  relate  this  information  to  the  earth- 
centered  earth-fixed  reference  frame  (ECEF) .  To  use  this  frame 
accurately,  knowledge  of  the  earth’s  physical  structure  and  shape  must 
be  known  precisely.  A  number  of  earth  models  have  been  utilized  but  the 
most  accurate  to  date  is  based  upon  the  World  Geodetic  System  1984  (WGS- 
84) .  The  system  models  the  earth  as  an  oblate  spheroid  defined  by  the 
terms  in  Table  2.1  [12].  The  system  defines  the  ECEF  frame  as  follows: 
x.-  lies  in  the  equatorial  plane  and  intersects  the  Greenwich 
Meridian 

ye-  lies  in  the  equatorial  plane  and  rotated  east,  orthogonal  to 
the  ze  axis 

ze-  coincident  to  the  earths  rotational  axis  and  pointing  north  in 
the  standard  right-hand  orthogonal 

The  ECEF  frame  is  only  one  of  the  frames  used  to  develop  an  INS 
navigation  solution.  The  INS  utilizes  other  frames  such  as  the  wander 
azimuth  frame  (in  the  case  of  the  LN-94)  and  the  body  frame.  To 
understand  the  wander  azimuth  concept  and  other  pertinent  frames,  a 
summary  of  the  system  reference  frames  follows: 
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Table  2.1  WGS-84  Parameters 


Parameter 

Definition 

Value 

“ie 

Angular  rate  of  Earth 

7 . 292115e-5  s'1 

a 

Semi -major  Axis 
(Equatorial  Radius) 

6378137  m 

b 

Semi-minor  Axis 
(Polar  Radius) 

6356752.3142  m 

e 

First 

Eccentricity 

0.0818191908426 

f 

Flattening 

(Ellipticity) 

0.00335281066474 

go 

Equatorial  Acceleration 
of  Gravity 

9.7803267714  ms'2 
32.087686258  fs'2 

1.  Earth  Centered  Earth  Fixed  (ECEF)-  The  ECEF  e- frame  of  the  LN- 
94  is  different  from  the  standard  WGS-84  convention.  The  Litton 
ECEF  frame  shown  in  Figure  2.1,  has  its  origin  at  the  center  of 
the  earth  with  the  ze  axis  at  the  intersection  of  the  equatorial 
plane  on  the  Greenwich  meridian  and  the  ye  axis  aligned  with  the 
north  pole .  The  x,  axis  is  orthogonal  to  this  plane  and 
intersecting  the  equator. 

2.  Navigation  Frame-  The  navigation  n- frame  is  oriented  in  an 
East,  North,  Up  (ENU)  convention  with  the  U  axis  pointing  in  the 
direction  of  the  local  vertical  as  shown  in  Figure  2.1. 

3.  True  Frame-  This  t- frame  represents  the  actual  latitude  and 
longitude  of  the  INS.  The  true  frame  is  rotated  about  the  U  axis 
in  a  counterclockwise  direction  at  an  angle,  a,  referred  to  as  the 
wander  angle.  When  this  angle  is  zero  the  navigation  frame  and 
the  true  frame  are  coincident  in  the  [x,y,z]t  -  [E,N,U]t 


(To  Aries) 


Figure  2.1  Litton  ECEF  and  Navigation  Reference  Frames 

convention.  For  this  application  the  wander  angle  will  generally 
not  be  zero.  Refer  back  to  Section  2.1  for  details  on  wander 
angle  mechanization.  In  the  FNU  85-1  specification,  reference  is 
made  to  the  wander  azimuth  frame  while  in  the  Litton 
documentation,  reference  is  made  to  the  true  frame.  These  frames 
are  the  same. 

4.  Platform  Frame-  The  platform  p- frame  is  coincident  with  the 
true  frame  in  an  errorless  system.  Typically,  however,  the  frames 
are  misaligned  by  small  attitude  angles.  This  three  dimensional 
misalignment  is  represented  by  <f>T,  $y,  and  <f>z  as  shown  in 
Figure  2.2  [17].  Refer  to  Section  2.1.2  for  tne  matrix  definition 
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U,  zt,  zc 
Up 


w&sm 


Figure  2.2  Navigation  Reference  Frames  (t-true,  p-platform,  c-computer, 
b-body)  4x,y,z  Tilt  Errors,  at  and  V’e  Wander  Angles 

of  these  angles.  The  misalignments  indicated  above  are  actually 
representative  of  the  physical  misalignments  of  the  components  as 
experienced  by  the  true  frame  when  transformed  from  the  gyro  and 
accelerometer  frames. 

5.  Computer  Frame-  The  computer  c-frame  represent  latitude  and 
longitude  as  indicated  by  the  INS.  As  in  the  other  frames,  when 
the  wander  angle  is  zero,  this  frame  is  coincident  with  the 
navigation  frame  as  shown  in  Figure  2.2.  As  discussed  previously, 
the  values  computed  by  this  frame  differ  from  the  quantities  in 


the  true  frame  because  of  computational  and  physical 
uncertainties . 

6.  Body  Frame-  The  body  b-frame,  Figure  2.2,  is  a  function  of  the 
orientation  of  the  vehicle  containing  the  INS.  For  an  aircraft 
application,  the  xb  axis  is  parallel  to  the  fuselage  in  the 
direction  of  vehicle  nose.  The  yb  axis  is  parallel  to  the  right 
wing  and  positive  in  that  direction.  The  zb  axis  is  positive  out 
the  bottom  of  the  fuselage  to  form  an  orthogonal  right-hand 
convention  frame  [3]. 

2.1.2  Coordinate  Transformations .  One  of  the  key  principles  of 
inertial  navigation  is  the  transformation  of  vectors  from  one  reference 
frame  to  another.  One  means  of  doing  this  is  using  the  direction  cosine 
matrix  (DCM) .  Section  2.1  discusses  a  number  of  these  transformations 
and  the  following  is  a  definition  of  these  and  some  of  the  other 
applicable  transformations.  Note  that  the  true  frame  convention  rather 
than  wander  azimuth  frame  convention  is  being  used  to  make  this  overview 
of  the  error  model  more  compatible  with  the  discussion  in  the  Litton 
document  [ 17 ] . 

For  the  ECEF  and  the  true  frames  [3]: 


(3) 


cosAcosa-sinLsinAsina  -(cosAsina+sinLsinAcosa) 
cosLsina  cosLcosa 

(sinAcosa+cosAsinLsina)  sinAsina-cosAsinLcosa 


sinAcosL 
sinL  ^ 
cosAcosL 


where : 
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A  -  terrestrial  longitude 
L  -  geodetic  latitude 
q  -  wander  angle 

For  the  ECEF  and  navigation  frame  [3]: 


(5) 


c  - 


cosA  -sinAsinL  sinAcosL 
0  cosL  sinL 

-sinA  -cosAsin L  cosAcosL 


(6) 


where : 


A  -  terrestrial  longitude 
L  -  geodetic  latitude 


For  navigation  and  true  frames: 


(7) 


where : 


<£  = 


cosa  -sina  0 
sina  cosa  0 
0  0  1 


(8) 


Note  that  the  only  misalignment  between  the  navigation  and  true  frames 
is  the  wander  angle,  a. 

For  the  true  and  body  frames  [3]: 


(9) 
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cosflsin  xf>  cosBcosx p  sin0 

sin^sin^ sin^>+cos^cosV>  sin<^sin0cosV>-cos^sin^>  -sin<£cos0 
cos<£sin0sin^>-sin<^cos^>  cos^sinflcosV>+sin^cos0  -cos4>cos8 


(10) 


where : 


4>  -  roll 
8  -  pitch 

i>  -  platform  azimuth 

Since  the  sensitive  axes  of  both  the  gyros  and  the  accelerometers  are 
considered  to  represent  the  body  axis  of  the  vehicle  for  a  strapdown 
mechanization,  the  transformation  from  the  sensor  frame  to  the 
navigation  frame  is  represented  by  the  body -to -true -frame  transformation 
matrix  [3], 

In  the  case  of  the  platform  and  the  true  frames,  recall  that  the 
only  difference  is  a  small  attitude  error  where  <f>  is  a  skew- symmetric 
matrix  representing  the  small  misalignment.  In  this  case  the 
transformation  is  [17]: 


7 


-  I+4>] 


z 


(ID 


where : 


4> 


0  4>z  -4>y 

~4>z  0  4>x 

*y  -K  0 


(12) 


2.1.3  LM-94  Error  Model.  This  section  presents  a  brief 

discussion  of  the  LN-94  error  model  and  identifies  the  system  states 
used  in  this  thesis.  The  reader  is  referred  to  the  Litton  CDRL  [17]  and 
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to  Hirning  [14]  and  Stacey  [26]  for  a  more  rigorous  analysis  of  the 
model . 

The  INS  error  states  change  much  more  slowly  than  the  system 
navigation  states  for  an  INS  in  a  dynamic  environment.  Consequently,  a 
longer  sampling  rate  can  be  used  and  the  computational  load  is  minimized 
because  these  error  states  can  be  linearized.  In  addition,  slower 
changing  states  allow  for  simplification  of  some  of  the  propagation 
equations  and  again  assist  in  reducing  computational  loading. 

The  linearized  INS  error  state  equation  is  of  the  form: 

6i(t)  -  F(t)6x(t)  *  (13) 


where : 


F(t) 


dF[x,  u(t),t] 
dx 


(14) 


6x(t)  is  a  time-varying  state  error  vector,  F(t)  is  a  time-varying 
system  dynamics  matrix,  w  is  a  white  noise  vector  with  G-I ,  and  Xj,  is 
the  nominal  value  of  x  in  the  linearization  process. 

The  LN-94  error  model  presented  In  Litton' s  CDRL  has  a  93 -state 
error  vector.  fix  is  partitioned  into  six  smaller  error  vectors  for 
convenience  of  analysis.  The  vectors  are  defined  as  follows: 

6x  =  [  fix*  <5x|  6xJ  6xl  &xl  &xl  ]  ^ 


where : 


5xx  represents  position,  velocity,  attitude,  and 
vertical  channel  errors  (13  states). 

6x2  represents  gyro,  accelerometer,  and  barometer 
correlated  errors  (16  states). 
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fix3  represents  gyro  bias  errors  (18  states) . 

Sx4  represents  accelerometer  bias  and  barometer  bias 
errors  (22  states) . 

£x5  represents  accelerometer  and  gyro  initial  thermal 
transients  (6  states) . 

£x6  represents  the  gyro  compliance  errors  (18  states). 
Definition  of  each  of  the  93  states  is  found  in  Appendix  B.  In  state 
space  matrix  form,  Equation  (13)  is  explicitly  represented  by  the 
following  equation  [17]: 


6xi 

**12 

Fl3 

Fl5 

Fib' 

Sx3 

vi 

6  i2 

0 

E 22 

0 

0 

0 

0 

Sx2 

V2 

6x3 

0 

0 

0 

0 

0 

0 

6x3 

0 

* 

6xa 

+ 

6xk 

0 

0 

0 

0 

0 

0 

0 

Sx5 

0 

0 

0 

0 

F55 

0 

Sx5 

0 

Sx6 

0 

0 

0 

0 

0 

0 

Sx6 

0 

The  dynamics  matrix,  F,  consisting  of  eight  non-zero  sub-matrices, 
represents  the  homogeneous  dynamics  of  the  system.  In  this  case,  the 
dynamic  matrix  is  a  linearized,  time -varying,  93x93  matrix.  The  reader 
is  referred  to  Appendix  C  for  the  definition  of  the  full  dynamics 
matrix . 

The  driving  noise  vector,  Gw,  is  a  Gaussian  white  noise  function 
of  the  form  [17]: 

Gw  =  [w*  wl  0  0  0 

The  autocorrelation  kernel  functions 
noise  matrices  are  [18]: 

E{Vl(t)wl(t  ♦  r))  *  Q11(t)6  (t  -  r)  (18) 


IT 

0 


(17) 


associated  with  the  two  white 
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£{w2(t)wj(t+r)}  =  Q22(t)6(t  -  r)  (19) 

where  S(t-r)  is  the  dirac  delta  function  and  Qn  and  Q22  represent  the 

white  noise  strengths.  The  form  of  the  Q  matrix  is  [17]: 

(20) 

The  definition  of  the  93-state  model  Q  matrix  is  found  in  Appendix  C. 

Computationally,  this  is  a  very  large  truth  model.  Ideally,  if  a 
model  could  be  developed  with  fewer  error  states  and  essentially  the 
same  performance,  the  job  of  propagating  this  model  would  be  much  less 
tasking.  Research  to  establish  an  effective  reduced  order  truth  model 
has  indicated  that  a  model  on  the  order  of  23  states  is  acceptable  for 
the  same  analysis  and  applications  [23,27].  The  most  significant 
partition  is  6xx  which  contains  the  basic  nine  error  states  defined  in 
Britting  [8]  and  the  necessary  baro-aiding  error  states.  The  addition 
of  the  first  ten  states  of  Sx2  accounts  for  gyro  drift,  accelerometer 
induced  errors,  gravity  vector  errors,  and  the  barometric  noise  error. 
This  model,  adjusted  with  appropriate  noise  strengths,  performs  well 
compared  to  the  Litton  documentation  [17,27], 

This  23-state  error  model  is  of  the  same  form  as  the  93-state 
error  model.  The  position  error  differential  equations  are: 

68x  =  -pysez  -  CRYSVy  (21) 


Qu  0  0  0  0  0 

0  Q22  0  0  0  0 

0  0  0  0  0  0 

0  0  0  0  0  0 

0  00000 
0  0  0  0  0  0 
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68y  -  Pxsez  * 

(22) 

68z  =  py68x  -  px68y 

(23) 

68x  yi  are  components  of  68  which  define  the  misalignment  from  the  true 
frame  to  the  computer  frame.  The  craft  rate,  p,  defined  as  the  angular 
rate  of  the  navigation  reference  frame  with  respect  to  earth,  has  the 
following  components: 

Px  =  -Vky  (24 


P  y  =  ^Vrx 


(25) 


Pz 


0 


(26) 


The  components  of  earth  spheroid  inverse  radii  of  curvature  are: 


C  =  — 

a 


1-  -  -f  (C.c(2,3)2  -2C»(2,1)2) 
<3 


(27) 


1-  —  -  f  (Cg  (2 , 3)  2  -  2  ( 2 , 2 )  2 )  1  (28) 

a  J 

where  the  equatorial  radius,  a,  and  the  earth's  ellipticity,  f,  are 
defined  in  Table  2.1.  Vehicle  altitude  corresponds  to  the  term  h. 

Vx  y  z  are  components  of  the  vehicle  velocity  with  respect  to  earth 
coordinates,  and  6Vxyz  are  errors  in  the  computed  velocity  with  respect 
to  the  true  velocity. 

The  platform  tilt  differential  equations  are: 

4>x  =  -cizsey  ♦  ft y68,  ♦  »z<f>y  -  uy*z  -  CRySVy  +  bXc  *  Vbx  (29) 
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<f>y  =  -  ftx&Bz  -  uz<t>x  *  wx^z  +  CRX5Vx  +  byc  *  ^by 


(30) 


4>z  =  -flyStfj  +0x66 y  +  wy<f>x  -  wx<t>Y  +  bZc  +  »7bi 


(31) 


where  the  earth  sidereal  rate,  fl,  more  often  referred  to  as  uit,  is 
computed  as  follows : 


0* 

(2,1) 

Qy 

“i.y 

S 

(2,2) 

<*>i« 

(2,3) 

(32) 


and  the  angular  rate  of  the  navigation  frame  with  respect  to  inertial 
space,  referred  to  as  spatial  rate  is  defined  as  follows: 

wx  =  Px  +  (33^ 

wy  *  py  +  fiy  (34) 

wz  =  Pz  +  nz  (35) 

The  variables  b(x  y  2)c  are  components  of  the  gyro  correlated  drift 
and  r)  is  a  white  noise  component  of  the  applicable  subscript,  in  this 
case,  gyro  white  noise. 

The  velocity  differential  equations  are  discussed  in  terms  of 
level  velocity  for  two  dimensional  problems,  or  level  and  vertical 
velocity  for  three  dimensional  problems.  The  level  velocity 
differential  equations  are: 
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(36) 


6VX  =  -2(1^  +  Vz(lz)88x  *  2 Vynx68y  ♦  2VZQ XS8Z 

-  ♦  v*  -  VzC*xSV*  +  2nzsvy 

-  (py  +  2Cly)6Vz  +  8gx  ♦  t lKx 

svy  -  2vxnysex  -  2(va  ♦  ^,>6^  ♦  2vzny68z 

+  4*x  -  -  2fit6Vx  -  VzCKYSVy  (37) 

+  (px  +  2nx)6Vt  +  6gy  +  VKy 

The  variables  8 gx  y  x  are  component  errors  in  the  gravity  vector  and 
Ajy  j  are  components  of  specific  force. 

Vertical  velocity  is  a  more  complex  problem,  given  that  the  model 
must  account  for  vehicle  acceleration  as  well  as  gravitational 
acceleration.  The  introduction  of  vertical  channel  gains,  klt  k2,  k3, 
and  k<,  to  the  model  (Equations  (47)  to  (50))  plus  the  more  complex 
effects  of  the  earth's  physical  shape,  contribute  to  this  complexity. 
Vertical  channel  differential  equations  are  defined  as  follows: 

6VZ  =  2Vxnz66x  +  2Vynz60y  -  2(Vyny  +  VJpx)68z 

-  V*  +  V,  +  iPy  +  2«y  *  VXC^)6VX 

-  (Px  *  2nx  -  VyCRy)6Vy  ♦  (2 go/a)Sh 
*  kz8hc  -  k2ShL  +  k28Sll  -  SS3  +  8gz  +  r 

8h  -  6VZ  -  k15hL  ♦  (kj-DSS*  ♦  k^h,. 

6i\  •  6h  -  8h^ 

SS3  -  k3ShL  -  k3SSt  -  k36hc 


(38) 

(39) 

(40) 

(41) 
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SS4  =  (fc4  -  1)5S4  +  ku6h L  -  Je^ 


(42) 


6hc  =  (~/95hc)  5hc  (43) 

6hc  -  fihg  ,  fihc  =  5hg  (44) 


where : 


6h  is  error  in  vehicle  altitude 

ShL  is  error  in  lagged  inertial  altitude 

6hc  is  barometer  correlated  bias  noise  error 

5S3  is  error  in  vertical  aiding 

6S4  is  error  in  vertical  aiding 

6hB  is  barometric  altitude  error 

£6hc  is  baro  inverse  correlation  time 

The  reader  is  referred  to  Figure  2.3  for  further  clarification  of  the 

vertical  channel  equations. 

Specific  force  measurements  are  not  a  part  of  the  model.  Specific 
force  information  is  obtained  from  the  following  transformation: 


(45) 


Measurements  for  the  simulation  are  provided  by  trajectory  data. 

The  vertical  channel  gains  are  calculated  based  on  the  following 
equations : 


Ai  -  100  1 


*[*! 


(46) 
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3  T3 


K  *  a 


where : 


A  -  |  ht  |  *  |  Vj  | 


30  fps  initially 


A0  +8  if  A0  <A 


A0  -8  if  A0  >A  and  A0  >38 


30  fps  otherwise 


A  summary  of  the  error  states  as  represented  in  their  respective 
differential  equations  is  defined  in  Table  2.2. 

2.1.4  Error  Model  Propagation.  The  model  is  defined  by  the 
previous  section  and  it  now  remains  to  discuss  the  method  used  to 
propagate  the  model  and  produce  the  information  necessary  for  the 
simulation. 

The  goal  of  the  simulation  is  to  produce  INS- indicated  information 
to  the  simulation  user.  As  mentioned  previously,  an  INS  is  not  error- 
free.  True  trajectory  is  defined  as: 

true  trajectory  *  INS  indicated  -  INS  error  (53) 


and  the  INS  indicated  value  is  represented  as: 
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Table  2.2  Reduced  Truth  Model  States 


State  Number 

Symbol 

Error  Definition 

1,2,3 

S Bx , S By ,60 z 

X, Y, Z  Position 

4,5,6 

tx'ty  4>z 

X,Y, Z  Platform  Tilt 

7,8,9 

6Vx,6Vy,6Vt 

X, Y, Z  Velocity 

10 

Sh 

Altitude 

11 

Lagged  Inertial 
Altitude 

12,13 

6S3,6S4 

Vertical  Aiding 

14,15,16 

^XC  >kyc  ,bI(. 

Gyro  Correlated 

Drift 

17,18,19 

?xc  ,  ^yc  >  V2C 

Accelerometer  and 
Velocity  Correlation 
Noise 

20,21,22 

6gx,6gy,Sgz 

Gravity 

23 

Shc 

Baro  Correlated 

Bias  Noise 

INS  indicated  *=  true  trajectory  *  INS  error 


(54) 


The  object  of  the  error  model  propagation  is  to  integrate  the  model 
forward  in  time,  and  when  coupled  with  the  trajectory  information  at  the 
end  of  the  applicable  interval  time,  to  simulate  the  INS-indicated 
values  as  defined  in  Equations  (53)  and  (54).  Specifically,  the  INS- 
indicated  position  is  defined  as: 


Lln» 

^ lOM 

sr 

rue+M 

^inM. 

(55) 


where : 
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SL  -  60ysina  -  60xcosa 


(56) 


6a  ■=  (50ycosa  +  6 6 x sinaj secL 


(57) 


6h  »  6h 


(58) 


and  the  wander  angle  error  equation  is  defined  as: 

6a  =  50,  -  SAsinL  (59) 


It  should  be  noted  that  Equations  (56)  through  (59)  are  only  valid  when 
not  operating  in  the  polar  regions.  The  equations  which  define  polar 
region  behavior  are  very  complex  and  are  not  considered  in  this 
analysis.  This  exclusion  prevents  the  simulation  of  the  INS  in  the 
polar  regions  although  future  implementation  is  an  option. 

To  propagate  the  model  it  is  important  to  consider  the  mod  1  in 
its  generalized  matrix  differential  equation  form: 

6x(t)  -  F(t)Sx(t)  +  £?(t)w(t)  (60) 

To  deal  with  this  model  in  a  digital  computer  environment,  the  discrete 
form  of  Equation  (60)  is  used.  The  solution  of  Equation  (60)  is  [18] : 

*'9  (ti,1,r)C(r)d^(r)]  (61) 


6x(ti,1)  *=  9  (ti^1,ti)6x(ti)  + 


r: 


which  in  turn  can  be  written  as  a  discrete  linear  stochastic  difference 
equation  [ 18 ] : 
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(62) 


6*(ti*i)  -  *  (Ci.l.tiJfixCti)  +  WdCtj) 

The  subscript.  d  Indicates  a  discrete  time  definition  and  the  value  vd 
takes  on  the  corresponding  bracketed  value  from  Equation  (61)  where  vd 
is  the  hypothetical  derivative  of  the  Brownian  motion,/).  The  matrix, 
fcCt.ti),  is  the  state  transition  matrix  associated  with  the  matrix 
F(ti).  It  should  be  noted  that  Equations  (60)  through  (62),  in  their 
most  general  form,  would  normally  have  a  deterministic  input  term  Bu(t) . 
The  simulation  will  not  use  any  deterministic  inputs,  as  they  are  not 
included  in  the  model. 

From  this  definition  it  can  be  seen  that  a  solution  to  the  INS 
truth  model  is  possible  by  the  evaluation  of  each  term  over  a  given 
computation  interval.  The  main  disadvantage  of  this  approach  is  the 
computational  burden  of  the  evaluation  of  $(ti+1,r). 

An  alternate  approach  is  to  integrate  the  first  term  of  Equation 
(60)  and  treat  the  noise  term  separately.  The  dynamics  of  9,  in  its 
linearized  error  state  form,  are  slow  enough  that  it  can  be  assumed 
that,  for  the  integration  interval,  9  is  constant.  Taking  advantage  of 
this  characteristic,  by  utilizing  a  numerical  integration  routine,  and 
adding  random  noise  wd  as  in  Equation  (62)  at  the  end  of  each 
computation  interval,  propagation  of  the  model  can  be  achieved. 

The  integration  routine  selected  to  propagate  these  equations  must 
be  both  efficient  and  accurate.  The  fourth-order  Runge-Kutta 
integration  routine  is  considered  to  be  a  very  capable  integration 
routine.  It  can  however,  suffer  from  accuracy  problems  and  does  not 
have  the  efficiency  to  handle  high  speed  computations  accurately  [24], 
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In  discussion  with  Maybeck  and  after  reviewing  the  techniques  used  in 
MSOFE,  the  technique  chosen  for  this  application  is  the  Kutta-Merson 
technique  [9.10,19], 

The  Kutta-Merson  routine  was  evaluated  against  a  number  of  other 
well  known  techniques  to  establish  the  best  method  for  integrating 
trajectory  type  problems.  The  Kutta-Merson  method  proved  to  excel  at 
handling  trajectory  driven  systems  such  as  the  one  in  this  thesis  [7], 
The  Kutta-Merson  equations  are  as  follows: 

7i  ■  y0  +  3*  *  f(x0,y0)  (63> 

y2  =  y0  *  *  f(x0,y0)  ♦  *  f(x0  +  ^h.yj  (64) 

7s  =  7o  +  *  ^(Xo.7o>  +  *  f<xo  +  3h>7i)  (65) 

7*  *  7o  +  *  ^(xo.7o)  -  \h  *  ^(xo  +  3^.72)  +  2h  *  f(xo  +  3*. 73)  (66) 

75  =  7o  +  3*  *  f(x0,y0)  +  *  f(x0  +  -^h,y3)  +  -5*  *  f(xo  +  h-7J  <67) 

where  h  is  defined  as  the  step  size  and  yn  is  the  solution  of  the  system 
equation  at  t0  plus  a  step  segment  of  h.  The  result  of  these  equations 
is  that  the  system  is  propagated  from  y(t0)  to  y(t0+h). 

The  technique  is  fifth  order  and  incorporates  automatic  step 
control  to  optimize  the  integration.  From  the  equations,  the  technique 
has  two  estimates  of  the  solution  at  the  end  of  the  step,  y4  and  y5. 

These  two  estimates  are  used  to  evaluate  step  size  validity  and  the  step 
is  adjusted  to  keep  the  error  within  the  designated  error  tolerance. 
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The  mechanics  of  this  technique  are  discussed  in  detail  in  Chapter  3, 
Section  3.3.1. 

The  “pprerch  that  is  n~.ct  commonly  -scd  to  simulate  the  noise  term 
wd  is  to  generate  random  noise  in  the  form  of  the  output  of  a  random 
number  generator  with  statistics  N[0,Qd].  For  a  discrete  case,  the 
statistics  of  wd  can  be  defined  as  [18]: 

FtVaCti)}  -  0 

£{wd(ti)wj(ti))  -  QaCti)  (68) 

£{w-(t1)wj(t1) )  *  0,  tL  *  tj 

The  quantity  Qd  can  he  approximated  by: 

Qd(ti-i)  =  C(ti)Q(ti)GI(t1)  At  (69) 

As  mentioned  earlier,  the  slow  dynamics  of  F(t)  allows  for  the 
assumption  that  the  dynamics  are  zero  over  the  integration  interval  and 
therefore  validates  Equation  (69)  as  an  approximation  to  Qd. 

To  achieve  the  necessary  statistics  for  wd,  the  numbers  associated 
with  the  number  generator  must  be  translated  into  statistics  N[0,Qd]. 
This  is  normally  achieved  by  taking  advantage  of  a  matrix  square  root 
algorithm  such  as  the  Cholesky  square  root  [18].  Given  a  vector  z  of 
random  number  with  statistics  N[0,I],  the  necessary  random  noise  can  be 
achieved  by  Equation  (70)  [19]. 

wd  -  v <7°) 

In  this  thesis,  however,  Q  in  Equation  (69),  is  diagonal  and  the 
square  root  algorithm  is  not  necessary.  Using  the  approximation  of 
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Equation  (69)  to  develop  Qd  and  since  G  -  I  ,  Qd  -  QAt.  From  this,  the 
value  of  white  noise  is  equated  as: 

vd  -  QAtz  (71) 

2.2  Intermetrics  INS  Simulation  Program 

The  Intermetrics  program  was  developed  to  operate  in  the  T-39 
Simulation  facility  at  Intermecrics  Inc.  The  facility  is  developed 
based  on  standard  form,  fit,  and  function  philosophy  and  is  used  to 
evaluate  the  components  of  navigation  systems,  specifically  GPS  at  this 
time  [6]  . 

The  program  is  a  communication  shell  simulating  INS  message 
traffic  based  on  the  SNU  84-1  [4]  and  the  MILSTD  1553B  communication 
protocol  [22] .  Navigation  simulation  is  limited  to  a  constant  heading 
and  constant  velocity  vehicle  trajectory  about  a  spherical  earth. 
Position  about  the  sphere  is  resolved  trigonometrically  based  on 
velocity  and  heading.  No  compensation  is  made  for  the  "real"  earth 
shape  or  for  conditions  such  as  the  Coriolis  effect  and  gravity.  No 
consideration  for  navigation  of  a  vehicle  under  acceleration  is 
provided.  Modelling  and  computation  of  INS  errors  are  nonexistent. 

The  program  is  PC-based  and  written  in  C  programming  language. 

Some  of  the  routines  are  also  written  in  assembly  language.  It  utilizes 
the  PC1553-2  Ballard  board  [5]  to  interface  to  the  1553B  bus.  The 
simulation  provides  the  capability  to  input  two  words,  D01  and  C01  of 
SNU  84-1,  and  read  the  output  words  101,  106,  107,  and  113.  D01  is  a 

generalized  input  to  the  INU  from  the  control  display  unit  and  CO 1  is 
input  from  the  CADC  to  the  INU.  101  outputs  the  INU  state  vector,  106 
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and  107  provided  output  to  the  HS I/HUD/DI S PLAYS ,  and  113  is  an  output 
initialization  vector.  The  reader  should  refer  to  the  SNU  84-1 
specification  [4]  for  details  on  the  content  of  these  words. 

The  program  provides  a  display  that  indicates  the  simulation  run¬ 
time,  the  INS  mode,  and  the  information  contained  in  one  of  the  input 
words  and  one  of  the  output  words.  The  displayed  words  are  selectable 
from  the  keyboard.  Present  latitude  and  longitude  are  displayed  and 
changed  as  the  simulation  progresses. 

The  program  must  read  a  data  file  which  contains  the  velocity  and 
heading  of  the  vehicle  in  order  to  initiate  the  simulation  in  navigation 
mode.  Velocity  and  heading  are  constant  and  only  one  input  can  be  made 
per  simulation  cycle.  The  simulation  has  OFF,  STANDBY,  AIR  ALIGN, 

STORED  HEADING  ALIGN,  GYROCOMPASS  ALIGN,  OVERFLY,  AUXILIARY,  ORIENT, 
ATTITUDE,  TEST,  CALIBRATE,  and  NAV  modes.  Modes  other  than  NAV  are 
completed  on  a  timing  cycle  and  the  appropriate  bits  are  set  in  the 
output  words.  NAV  mode  is  updated  by  the  simple  navigation  technique 
mentioned  previously.  The  simulation  also  has  waypoint/markpoint 
capability.  No  emphasis  is  placed  on  this  particular  capability  at  this 
time . 

The  simulation  acts  as  a  remote  terminal  on  the  1553B  bus  and  the 
communication  protocol  is  in  the  form  of  remote  terminal  to  bus 
controller  or  bus  controller  to  remote  terminal  transfers.  MILSTD  1553B 
protocol  is  discussed  in  some  detail  in  the  next  section.  User 
interface  with  the  simulation  is  through  the  terminal  keyboard  and 
through  the  bus  controller.  Once  the  simulation  is  started,  all  further 
communications  is  achieved  through  the  1553B  data  bus. 
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2.3  MILSTD  1553B  Data  Bus 


MILSTD  1553  is  a  document  which  establishes  a  military  standard 
for  a  communication  system  known  as  an  Aircraft  Internal  Time  Division 
Command/Response  Multiplex  Data  Rus  [22].  It  is  a  1  Mbps  serial  bus 
system  which  achieves  avionics  and  stores  management  integration  within 
an  aircraft  system.  The  standard  provides  methods  of  communication  and 
the  electrical  interface  for  sub-systems  connected  to  the  data  bus. 

The  key  components  of  the  system  are  the  bus  controller  (BM) , 
remote  terminal  (RT) ,  bus  monitor  (BM) ,  twisted  shielded  pair  wire  data 
bus,  and  coupling  transformers.  The  bus  controller,  as  its  name 
implies,  provides  "absolute"  control  over  transmission  flow  on  the  bus. 
It  controls  all  communications  on  the  bus  and  utilizes  a  command  and 
response  protocol  method  to  communicate  across  the  bus.  The  controller 
uses  this  method  to  control  the  system  remote  terminals,  thereby 
controlling  up  to  32  sub-systems. 

The  remote  terminal  may  be  represented  in  two  forms,  the  stand¬ 
alone  concept,  and  the  embedded  concept.  In  the  stand-alone  concept, 
the  RT  is  solely  dedicated  to  the  bus.  Its  only  function  is  to 
communicate  with  the  bus.  It  provides  the  interface  between  the 
controller  and  bus  and  a  non-1553  system.  System  design  may  permit  a 
stand-alone  RT  to  also  act  as  a  bus  controller.  Note  that  a  bus  can 
only  have  one  bus  controller  at  a  time. 

In  the  embedded  concept,  the  RT  consists  of  interface  circuitry 
embedded  in  the  sensor  or  sub-system.  It  performs  the  data  transfer  in 
and  out  of  the  sensor  but  generally  does  not  have  controller  capability. 
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This  configuration  is  the  typical  approach  in  most  Air  Force  equipment 
and  is  the  case  for  the  LN-94  INS. 

The  bus  monitor  monitors  all  messages  and  collects  data  for  mass 
storage  or  remote  telemetry.  It  may  also  serve  as  a  back-up  controller 
while  observing  the  system  state  and  operational  mode. 

The  bus  itself  is  composed  of  a  twisted  shielded  pair  wire  which 
is  coupled  to  the  RT's  and  the  bus  controller  by  a  bus  coupler.  The 
coupler  provides  isolation  between  the  bus  and  the  terminals  either  by 
direct  coupling  or  transformer  coupling. 
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Figure  2.4  Information  Transfer  Formats 

1553  protocol  consists  of  10  message  types  as  shown  in  Figures  2.4 
and  2.5.  Within  each  message  there  are  control  words  called  command  and 
status.  Messages  also  contain  data  words  which  provide  the  necessary 
data  to  communicate  on  the  bus.  The  messages  are  divided  into  two 
formats;  information  transfer  formats  and  broadcast  Information  transfer 
formats.  The  controller  uses  information  formats  to  address  individual 
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RT's,  while  broadcast  messages  address  the  entire  bus  or  segments 
thereof. 
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Broadcast  Information  Transfer  Formats 
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Figure  2.6  Mil  Std  1553B  Word  Formats 


In  the  information  transfer  format,  each  valid  message  sent  must 
be  acknowledged  by  an  RT  status  wc  i;  hence,  the  command/response 
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protocol.  Each  word  is  20  bits  in  length  and  consists  of  3  synch  bits, 
16  data  bits,  and  1  parity  bit.  Details  of  the  word  structure  are  shown 
in  Figure  2.6. 

The  command  word  can  only  be  generated  by  a  bus  controller  and 
provides  to  the  RT  the  necessary  information  about  the  message  to  be 
transmitted.  The  command  word  address  is  the  address  of  the  RT  that  is 
to  be  controlled.  The  command  word  may  be  followed  by  another  command 
word,  by  a  data  word(s),  or  a  wait  time  to  allow  the  RT  to  respond  with 
a  status  word. 

The  status  word,  the  response  portion  of  the  protocol,  is  utilized 
by  the  RT  to  inform  the  bus  controller  that  a  valid  reception  or 
transmission  has  taken  place.  Conversely,  the  bus  controller  utilizes 
the  status  word  to  monitor  the  health  of  RT's  and  the  system  as  a  whole. 
The  RT  sets  bit  flags  in  the  status  word  which  are  then  interpreted  by 
the  bus  controller. 

Transmission  flow  may  be  bus  controller  to  RT,  RT  to  bus 
controller,  RT  to  RT,  or  as  in  the  case  of  broadcast  messages,  bus 
controller  to  a  number  of  RT's.  Again,  all  transmissions  are  controlled 
by  the  controller  using  command  words  to  address  RT's  and  command 
functions . 

As  mentioned  in  Section  2.2,  the  INS  simulation  is  an  RT  and  in 
this  case  the  address  is  05.  The  bus  controller  is  emulated  by  a  DTI 
1120  board  [13]  in  another  PC  (see  next  section).  The  applicable  words 
and  formats  for  the  1553B  bus  for  use  in  the  simulation  are  provided  in 
Appendix  A. 
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2 . 4  Hardware 


The  simulation  is  written  to  operate  under  MS  DOS  using  an  Intel 
80286  or  80386  processor.  This  particular  installation  is  a  386-based 
33  Mhz  PC.  The  PC  also  has  a  Cybex  80C387  math  co-processor  to  assist 
in  the  computational  loading  on  the  main  processor.  Data  storage  is 
provided  in  the  form  of  a  120  Mbyte  hard  disk  and  a  1.2  Mbyte  5.25 
floppy  disk  drive. 

The  1553B  data  bus  is  achieved  by  using  a  Ballard  Technology 
PC1553-2  interface  board  with  the  associated  driver  software  [5].  The 
1553B  bus  controller  is  emulated  by  a  PC  operating  a  Digital  Technology 
DTI  1120  board  with  the  SCE4  application  software  [13] .  The  bus  is 
cabled  between  the  DTI  1120  board  and  the  PC1553-2  interface  board. 

2.5  Software 

A  number  of  commercial  software  packages  are  used  to  develop  the 
simulation.  They  are  as  follows: 

1.  Microsoft  C  Compiler  Version  6.0  [20] 

2.  Microsoft  Macro  Assembler  Version  5.1  [21] 

3.  Essential  Software  C  Utility  Library  Version  3.0  [11] 

4.  Ballard  Technology  Microsoft  C  Linkable  PC1553  Driver  [5] 

5.  Digital  Technology  SCE4  Application  Software  for  the  DTI  1120 
interface  board  [13] 

6.  Companion  disk  software  for  reference  [24] 

In  addition,  INERCA  [15],  a  trajectory  generator  developed  by  the  US  Air 
Force,  was  used  to  develop  the  vehicle  trajectories  for  the  simulation. 
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2.6  Sunwnary 


This  chapter  presents  the  theory  on  which  the  simulation  is  based. 
The  LN-94  is  a  ring  laser  gyro  strapdown  INS  which  is  implemented  as  a 
locally  level  wander  azimuth  mechanization.  The  original  93-state  truth 
model  is  reduced  to  23- states  and  the  model  differential  equations  are 
defined  by  Equation  (21)  through  to  Equation  (52).  Table  2.2  summarizes 
the  states  used  in  the  reduced  model.  The  model  is  linearized  and 
represented  by  error  states  rather  than  whole  states.  This  approach 
reduces  the  computation  workload  of  the  simulation. 

The  INS  indicated  values  are  developed  as  the  sum  of  true 
trajectory  and  INS  error.  The  true  trajectory  is  provided  by  the  INERCA 
trajectory  generator  and  the  errors  are  developed  through  integration  of 
the  error  model  using  the  fifth-order  Kutta-Merson  integration  routine. 
The  stochastic  behavior  of  the  model  is  provided  in  the  form  of  a  random 
number  generator  with  output  statistics  N[0,Qd]  where  Qd  is  approximated 
by  Equation  (69). 

The  Intermetrics  Simulation  [1]  forms  the  groundwork  for  the 
simulation.  However,  it  should  be  noted  that  the  simulation  developed 
in  this  thesis  bares  little  resemblance  to  this  program  as  a  consequence 
of  the  additions /changes  that  are  implemented. 

The  simulation  operates  under  MS  DOS  on  an  IBM  compatible  80386 
33-Mhz  PC  with  a  Cybex  math  coprocessor.  The  simulation  communicates 
through  the  MILSTD  1553  communication  bus  and  provides  information  to 
the  user  based  on  the  FNU  85-1  Specification  [3], 
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III.  Program  Development 


The  executable  program,  INS_LN94,  consists  of  35  functions,  not 
including  MAIN,  and  10  commercially  developed  functions,  all  encompassed 
in  the  INS_LN94  source  code  and  the  five  linked  object  modules.  This 
seems  complex,  but  a  close  look  at  the  logic  flow  and  control  provides  a 
good  understanding  of  the  program. 

This  chapter  provides  an  overview  of  the  program,  including  logic 
flow  and  an  explanation  of  the  MAIN  function.  This  chapter  includes  a 
discussion  of  the  propagation  technique  used  to  process  the  simulation. 
Also  provided  are  some  insights  as  to  the  design  philosophies  for  the 
program  and  considerations  that  were  kept  in  mind  when  the  program  was 
being  developed.  The  development  tools  are  identified  and  reasons  for 
their  use  are  outlined. 

The  intent  of  this  chapter  is  to  show  the  global  picture  of  the 
program.  The  reade -  ?s  referred  to  Appendix  E  for  a  description  of  each 
function  and  to  the  source  code  for  detailed  coding  information. 

Appendix  F  provides  the  necessary  information  on  preparation  and 
operating  procedures. 

As  clarification  to  notation,  all  program  variables  and  language 
syntax  are  capitalized  to  differentiate  from  the  text.  When  referring 
to  INS_LN94,  this  implies  the  entire  executable  program  which  includes 
the  linked  modules. 

Specifically,  this  chapter  is  segmented  into  the  following 
subj  ects : 
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1 .  Program  Overview 

2 .  Function  MAIN 

3.  Model  Propagation  Method 

4 .  Information  Storage 

5.  Programming  Considerations 

6.  Development  Problems  and  Tradeoffs 

7.  Trajectory  Generation 

3.1  Program  Operation  Overview 

INS_LN94  is  a  simulation  of  an  LN-94  Litton  Systems  inertial 
navigation  system.  Through  a  simple  question  and  answer  interactive 
shell,  the  user  can  select  a  flight  trajectory,  a  navigation  session 
length,  and  storage  of  specified  data.  The  simulation  incorporates  a 
23 -state  error  model  and  stochastic  white  noise  injection  to  emulate  the 
LN-94  INS.  A  Kutta-Merson  fifth-order  integration  routine  is  used  to 
integrate  the  system  forward  in  time.  The  simulation  responds  to  a 
MILSTD  1553  bus  controller  and  provides  two  output  messages  to  the  bus. 

The  INS_LN94  is  essentially  a  two-part  program.  It  has  an 
operating  shell  which  controls  entry  into  and  out  of  the  simulation, 
provides  for  parameter  initialization,  and  provides  plotting 
capabilities  so  the  user  may  analyze  data  that  has  been  generated. 

Within  the  control  shell  is  the  simulation  process  itself,  which  is  in 
the  form  of  the  model  propagation  and  input/output  processes. 

The  program  begins  with  a  narrative  overview  of  the  simulation  and 
provides  details  on  operation  procedures  to  the  user.  The  simulation 
continues  with  a  number  of  questions  to  the  user,  the  answers  to  which 
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declare  parameters  to  control  the  overall  operation  of  the  simulation. 
Following  these  questions,  the  simulation  sets  the  video  screen  to  the 
simulation  format  and  simulation  commences. 

From  the  questions  provided  to  the  user,  a  number  of  choices  are 
available.  The  simulation  permits  the  use  of  three  possible  vehicle 
trajectories:  static  navigation,  straight  and  level  trajectory,  and  the 
Litton  fighter  trajectory.  The  simulation  permits  varying  navigation 
session  lengths  up  to  the  limits  of  the  particular  trajectory.  The 
fighter  trajectory  is  limited  to  a  two  hour  flight,  the  static 
navigation  has  no  time  limit  and  the  straight  and  level  flight  has  a  six 
hour  time  limit. 

The  user  can  store  data  to  files.  A  choice  of  error  states  or 
whole  states  is  provided.  Error  state  collection  is  limited  to  14 
states  from  the  error  model.  The  whole  states  are  the  INS- indicated 
values  provided  by  the  simulation  and  again  the  limitation  of  14  files 
of  data  is  imposed.  Refer  to  Section  3.4  for  a  complete  list  of  the 
whole  states  and  error  states  that  are  tracked  and  stored  to  file.  In 
conjunction  with  data  collection,  the  user  can  define  the  data 
collection  rate  by  indicating  the  number  of  seconds  between  collection 
points.  This  feature  gives  the  user  flexibility  with  respect  to  storage 
space,  an  important  option  depending  on  the  system  in  use. 

On  entry  into  the  simulation,  the  user  must  align  the  system.  The 
simulation  will  not  enter  navigation  mode  until  the  system  is  aligned. 
Alignment  is  simulated  by  a  timing  cycle.  No  "real”  alignment  takes 
place  but  the  simulation  indicates  and  follows  the  steps  necessary  to 
display  alignment  status.  A  four  minute  alignment  takes  place  and  the 
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system  state  vector  is  initialized  with  typical  four  minute  alignment 
values.  These  alignment  values  are  fixed  for  all  simulations. 

The  user  can  select  modes  of  operation  with  the  defined  function 
keys  or  exit  the  simulation  by  using  the  escape  key.  The  user  may 
monitor  one  of  two  output  messages  and  the  input  message.  The  two 
output  messages  contain  the  navigation  parameters  of  interest  and  are  in 
response  to  command  words  #1  and  #24  of  the  FNU  85-1  specification.  The 
input  message  provides  present  position  latitude  and  longitude  and  is 
formatted  in  accordance  with  and  in  response  to  command  word  #2 .  The 
user  must  initialize  present  position  latitude  and  longitude  prior  to 
starting  the  navigation  session. 

The  user  is  provided  with  the  simulation  time  to  monitor  progress 
of  the  simulation.  Only  stationary  navigation  does  computations  in  real 
time.  Due  to  computational  overhead,  the  other  trajectories  are  not 
done  in  real  time.  Refer  to  Section  3.6  for  more  detail  on  this  issue. 

After  the  simulated  flight  the  user  has  the  option  of  plotting 
stored  data  to  the  screen  or  to  a  printer  using  a  routine  celled  EZPLOT. 
It  is  a  simplified  plotting  utility  made  for  the  USAF.  Other  options 
include  exiting  the  program  or  restarting  the  simulation. 

Figure  3.1  shows  the  program  hierarchy  of  the  executable  program. 
All  source  is  written  in  C  programming  language  except  CLKT10.0BJ  and 
INS_INT2 . OBJ ,  which  are  written  in  assembly  language.  Assembly  language 
is  used  in  these  cases  to  provide  easy  access  to  the  machine  level 
operations  of  the  PC  and  the  Ballard  board.  The  function  MAIN  is  part 
of  INSLN94.C.  The  five  object  modules  contain  functions  that  are 
called  by  MAIN.  The  Microsoft  library  [20]  is  included  as  part  of  the 
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compiler  used  to  develop  the  program  and  the  Essential  library  [11]  is 
linked  as  an  additional  library.  MCDRVL.OBJ  is  the  object  module 
provided  by  Ballard  Technology  [5]  to  operate  the  PC1553  interface 
board.  Further  details  on  program  structure  and  compilation  are 
provided  in  Section  3.5. 


Figure  3.1  INS_LN94  Program  Architecture 


3.2  Function  MAIN 

Like  all  C  programs,  the  program  global  control  is  developed  and 
contained  in  the  function  MAIN.  As  can  be  seen  from  Figure  3.1,  MAIN 
also  provides  control  over  the  five  object  modules.  To  understand  how 
MAIN  provides  this  control,  a  flow  chart  is  provided  in  Appendix  D, 
Figure  D.l  through  Figure  D.4.  Reference  to  these  charts  as  the 
discussion  progresses  aids  in  understanding  the  logic  flow. 

Before  executing  the  simulation,  MAIN  asserts  TEST_1553  which 
tests  for  the  presence  of  a  Ballard  PC1553  interface  board.  Without  the 
board,  the  simulation  cannot  be  implemented  on  the  1553  bus.  Once  it 
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has  been  determined  that  the  computer  has  the  appropriate  hardware,  the 
simulation  setup  and  processing  begins. 

The  MAIN  function  has  a  number  of  decision  processes  that  control 
the  operation  of  the  program.  Examining  the  flow  charts  it  can  be  seen 
that  there  are  really  only  three  major  control  points  in  the  function. 
The  first  control,  working  from  the  outside  loop  to  inside  is,  WHILE 
! SIMULATION_OFF,  which  maintains  control  over  the  entire  program.  The 
second  control  is  WHILE  EXIT_FLAG  which  maintains  control  over  the 
simulation  processing  operation.  The  third  control  is  an  if  statement, 
IF  (HUNDRED_MS ( ) ) ,  which  controls  timing  and  propagation  of  the  model 
itself.  Within  IF  (HUNDRED_MS ( ) )  there  are  a  number  of  control 
statements.  They  rely  on  timing  for  operation  and  are  therefore 
considered  secondary. 

Figure  D.l  shows  that  WHILE  ! SIMULATION_OFF  starts  by  introducing 
the  program  with  INTRODUCTION  and  performs  all  the  Initializations  prior 
to  entering  the  actual  simulation  using  INITIALIZE  and  DISPLAY_SCREEN . 
Control  is  then  passed  to  WHILE  EXIT_FLAG  for  the  simulation  process. 

As  shown  in  Figure  D.4,  once  the  simulation  process  has  terminated,  the 
orogram  enters  PLOT_RESULTS ,  which  gives  the  user  the  capability  to  plot 
simulation  results  or  use  the  SIMULATION_OFF  variable  to  terminate  the 
program.  INTRODUCTION  also  provides  the  user  an  opportunity  to 
terminate  the  program  prior  to  entering  the  simulation  process.  These 
are  the  only  two  areas  where  SIMULATION_OFF  is  accessed.  Anytime  the 
variable  SIMULATION_OFF  is  TRUE,  the  program  will  terminate. 

The  second  control,  nested  in  WHILE  ! SIMULATION_OFF,  is  WHILE 
EXIT_FLAG,  which  maintains  controls  of  the  simulation  process.  This 
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loop  takes  control  of  the  simulation  once  the  simulation  screen  has  been 
displayed.  The  main  purpose  of  this  loop  is  to  give  the  user  the 
capability  to  exit  from  the  display  screen  and  simulation  process  in  an 
orderly  fashion.  Anytime  the  user  wishes  to  exit  the  simulation,  the 
ESC  key  can  be  input  from  the  keyboard  and  the  program  performs  an 
orderly  exit  from  the  simulation.  The  loop  starts  by  initializing  the 
simulation  by  reading  data  from  the  1553  bus  and  setting  the  present 
position  in  the  simulation  with  Process_CMD_2 .  The  third  control  loop 
is  then  encountered. 

This  third  control  provides  the  timing  of  the  simulation  and 
stipulates  when  to  call  the  necessary  routines  to  propagate  the  system 
model.  HUNDRED  MS  tracks  the  passing  of  each  10  ms  time  interval.  This 
is  achieved  by  first  setting  the  timer  ENBTIM  and  new  interrupt  handler 
in  INITIALIZE.  This  is  achieved  by  replacing  DOS  interrupt  0  with  a  new 
interrupt  handler  and  decreasing  DOS  timer  0  to  call  the  interrupt 
handler  every  10  ms.  When  the  interrupt  is  called,  a  variable  is 
incremented  and  this  is  tracked  by  HUNDRED_MS  and  the  function  indicates 
the  passing  of  each  100  ms.  The  DOS  interrupt  handler  continues  to  be 
called  at  18.2  Hz  to  maintain  computer  system  integrity. 

The  main  disadvantage  of  this  approach  is  that  certain  DOS 
functions  will  be  affected  by  the  changes  made  to  the  DOS  timer  and 
interrupt  procedures.  For  example,  the  file  date/time  stamp  will  be 
incorrect.  The  advantage  of  this  approach  is  that  timing  may  now  be  set 
up  to  process  in  multiples  of  100  ms,  a  simple  number  to  manipulate. 
Using  this  technique,  the  propagation  functions  are  started.  See 
Appendix  E  for  detail  on  these  functions. 
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To  make  the  simulation  a  real-time  process,  the  computations  to  go 
from  ti  to  t2  must  be  faster  than  the  actual  time.  Through  some 
experimentation,  it  was  determined  that  processing  every  second  provided 
a  viable  time  frame  for  processing  as  well  as  a  reasonable  time  frame 
between  screen  updates  and  writing  to  the  1553  bus.  Any  shorter  time 
interval  tends  to  increase  the  computation  overhead,  not  so  much  in  the 
integration  but  in  the  process  to  initiate  and  return  from  the 
propagation  function.  Any  longer  time  starts  to  introduce  timing 
complications  for  other  functions  in  the  simulation.  Accordingly,  at 
each  second  of  expired  time,  the  simulation  will  enter  the  propagation 
cycle . 

To  control  the  length  of  time  the  system  propagates,  and  to  ensure 
propagation  does  not  take  place  until  the  system  is  aligned,  the 
following  if  statement  is  used: 

IF  (OP_MODE  —  NAV  &&  NAV_RDY  && 

( (TIME(&CRRT_TIME)  -  ST_TIME_NAV)  <  SESSION_LENGTH) ) 
ST_TIME_NAV  is  set  when  the  simulation  enters  NAV  mode  and  this  is 
compared  to  system  time.  As  long  as  the  result  is  less  than 
SESSION_LENGTH ,  the  propagation  cycle  can  be  started.  If  all  other 
conditions  are  met,  the  simulation  begins  to  propagate.  As  long  as  the 
session  length  has  not  expired  or  the  user  has  not  selected  the  ESC  key, 
the  simulation  will  continue  to  propagate.  The  cycle,  once  entered, 
propagates  until  the  one -second  propagation  interval  has  been  completed. 
The  key  to  real-time  processing  is  that  this  interval  must  be  completed 
in  less  than  one  second  in  order  to  return,  process  all  other  functions, 
and  be  prepared  to  propagate  again  at  the  beginning  of  the  next  second. 
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Following  PROPAGATE,  the  simulation  enters  the  function 
INS_ERROR_INCLUDE .  This  function  processes  the  errors  and  trajectory 
data  into  whole  state  values.  These  values  are  then  converted  to  the 
format  necessary  to  output  on  the  1553  bus.  Storage  of  whole  and  error 
states  is  also  performed  in  this  function. 

In  the  same  time  period  and  following  propagation,  the  functions 
PR0CESS_CMD_1  and  PROCESS_CMD_24  are  called  to  calculate  the  INS- 
indicated  measurements  and  to  format  the  data  to  be  sent  to  the  1553 
bus.  UPDATE  is  also  called  to  update  the  processed  information  to  the 
screen. 

Every  second  as  well,  but  out  of  synch  from  propagation  by  300  ms, 
is  the  function  MsgCmdProc .  This  function  processes  any  commands  that 
are  input  from  the  keyboard.  The  function  is  set  out  of  synch  with  the 
propagation  process  to  lessen  the  computational  burden  over  that  time 
frame  and  as  a  convenience  so  that  the  propagation  functions  can  be 
controlled  more  precisely  in  their  own  control  process.  The  final 
function  that  is  called  in  this  timing  structure  is  WRITERTDWD,  which  is 
a  1553  function  to  pass  processed  data  to  the  1553  bus. 

As  the  program  steps  out  of  the  timing  structure,  a  check  is  made 
as  to  the  status  of  the  navigation  session.  If  the  session  is  ended  by 
elapsed  time,  IF  FINISH_SESSION  prepares  the  simulation  to  exit.  A 
message  is  displayed  to  the  screen  to  indicate  the  end  of  the  session. 
The  EXIT_FLAG  variable  is  set  to  TRUE  and  the  simulation  exits  to  WHILE 
! SIMULATION_OFF  control. 

Once  back  into  the  main  loop  control,  the  timer  and  interrupt 
handler  are  reset  to  system  values  using  REM_HDLR  and  DISTIM.  Open 


files  are  closed  and  the  routine  enters  PLOT_RESULTS .  Once  in 
PLOT_RESULTS ,  the  user  may  select  to  plot  results,  to  restart  the 
simulation,  or  to  exit  the  program.  The  program  calls  a  routine  called 
EZPLOT  to  do  any  plotting  requirements.  Once  plotting  is  complete  and 
the  user  wishes  to  exit,  the  program  processes  the  library  function  EXIT 
to  monitor  the  program  status  at  termination  and  to  perform  an  orderly 
closure  of  the  program. 

3.3  Method  of  Model  Propagation 

Propagation  of  the  system  error  model  is  controlled  from  within 
the  function  PROPAGATE.  This  section  outlines  the  PROPAGATE  process  and 
shows,  through  the  use  of  flow  charts,  the  integration  technique  used  to 
propagate  the  model. 

The  PROPAGATE  function  is  called  within  the  timing  structure  at 
one -second  intervals  and  only  when  the  simulation  has  been  aligned,  the 
operational  mode  is  NAV,  and  the  navigation  session  has  not  expired. 
Figure  D.5  shows  the  logic  flow  of  the  function.  PROPAGATE  is  directly 
responsible  for  the  integration  of  the  error  model.  In  addition,  it 
provides  the  noise  injection  capabilities  that  are  necessary  to  emulate 
the  real  INS  properly. 

PROPAGATE  calls  two  other  functions  within  its  process.  The 
first,  INTEGRATE,  is  the  integration  technique  used  in  the  simulation. 
Chapter  2,  Section  2.1.4  outlines  the  philosophy  f^r  selecting  this 
fifth-order  Kutta-Merson  routine.  It  is  a  variation  of  the  FORTRAN 
routine  that  is  used  in  MSOFE  [9,10],  Changes  were  made  to  accommodate 
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the  routine  in  C  language  and  to  use  ic  specifically  for  this 
simulation.  Section  3.3.1  provides  more  detail. 

The  second  function,  NOISE,  is  a  variation  of  the  function  found 
in  [24]  and  provides  the  randomly  generated  noise  strengths  with 
statistics  N[0,Qd],  which  represents  the  stochastic  white  Gaussian  noise 
that  is  required  to  implement  the  system  uncertainties  during 
propagation.  Refer  to  Appendix  E  for  more  detail. 

As  discussed  in  the  previous  section,  PROPAGATE  is  called  from 
within  the  timing  structure  to  propagate  the  system  model  over  a 
specified  time  frame.  PROPAGATE  needs  the  value  of  the  end  time  which 
represents  the  time  to  which  the  function  will  propagate  before 
returning  to  MAIN.  End  time  is  incremented  one  second  and  passed  to 
PROPAGATE.  Recall  that  the  one -second  interval  discussed  in  the  last 
section  represents  the  optimum  processing  time  to  maintain  real  time. 
Once  end  time  has  been  passed  to  PROPAGATE,  the  process  of  integration 
over  a  one  second  interval  begins. 

PROPAGATE  is  controlled  in  a  similar  fashion  as  MAIN.  It  is 
encompassed  by  a  decision  loop,  WHILE  ! FINISH.  The  purpose  of  this  loop 
is  t-  continue  the  integration  function  until  end  time  has  been  reached. 
Depending  on  the  trajectory,  this  process  can  be  achieved  in  a  one- 
second  step,  or  as  the  trajectory  becomes  more  dynamic,  the  one -second 
interval  may  be  segmented  into  a  number  of  smaller  steps.  The  loop  also 
gives  the  capability  to  return  from  the  function  INTEGRATE  to  add  noise 
at  each  step  interval. 

End  time  is  passed  and  INTEGRATE  is  called  as  the  first  step  in 
PROPAGATE.  On  return  from  INTEGRATE,  the  status  of  the  integration  is 
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checked  to  ensure  no  errors  occurred  prior  to  continuing.  If  an  error 
has  occurred,  the  simulation  terminates  and  an  error  message  is 
displayed  to  the  screen.  The  next  step  is  to  check  the  state  that  the 
propagation  is  in.  If  at  a  step  interval  or  at  the  end  of  the 
integration  interval,  the  function  computes  the  At  which  represents  the 
difference  in  time  between  the  present  time  and  the  last  time  that 
was  computed.  NOISE  is  then  called  and  the  result  is  added  to  the 
solution  vector  from  the  integration  function.  The  final  step  is  to 
check  if  time  has  reached  end  time.  If  this  is  true,  the  variable 
FINISH  is  set  to  TRUE  and  the  function  exits  the  loop  and  returns  to 
MAIN.  Else  the  function  steps  through  the  propagation  process  again. 

3.3.1  Function  INTEGRATE.  This  function  is  the  most  complicated 
of  all  the  program  functions.  It  represents  the  basis  of  the 
computations  used  to  propagate  the  error  model.  Figure  D.6  through 
Figure  D.8  show  the  logic  flow  of  the  function.  The  flow  chart  and  the 
following  discussion  are  limited  to  general  logic  flow  and  not  a 
variable-by-variable  analysis.  The  intent  is  to  give  the  reader  an 
understanding  of  the  approach  and  not  the  exact  programming  techniques. 

As  indicated  earlier,  the  integration  technique  used  is  a  fifth- 
order  Kutta-Merson  process.  Automatic  step  sizing  is  incorporated  into 
the  routine.  By  using  the  variables  assigned  in  INITIALIZE,  the 
integration  routine  may  provide  continuous  noise  injection  or  noise  at 
the  end  time.  In  addition,  the  routine  can  be  set  to  have  a  fixed  step 
size  or  may  enter  an  error  checking  process  and  adjust  the  step  size 
automatically.  The  user  also  provides  a  maximum  and  minimum  step  size 
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and  the  error  tolerance  for  the  error  checking  process.  These  variables 
are  found  in  INITIALIZE  as  well. 

Once  control  is  passed  to  INTEGRATE,  the  first  operation  that  is 
performed  is  to  initialize  variables  and  check  to  ensure  the  parameters 
are  within  the  range  expected  for  the  integration  routine.  This  process 
is  only  done  once  at  the  beginning  of  the  simulation.  Comparisons  are 
then  made  between  the  time  interval  of  integration  and  the  computer 
epsilon  to  determine  if  the  interval  is  within  the  resolution  of  the 
machine  floating  point  operations.  Computer  epsilon  is  a  measure  of  the 
resolution  of  floating  point  number  for  the  computer  being  used  to 
execute  the  program. 

If  the  interval  is  too  small,  the  integration  is  done  using  the 
Euler  method  and  results  are  returned  to  PROPAGATE.  This  is  necessary 
since  the  Kutta-Merson  technique  further  divides  the  time  Interval, 
which  will  then  be  out  of  range  of  the  computer  floating  point 
operations  and  return  erroneous  values.  Note  that  epsilon  for  a  PC  has 
been  independently  computed  and  is  a  defined  constant  in  the  program  for 
double  and  single  precision  operations. 

If  the  interval  of  integration  is  large  enough  to  permit  step 
sizing,  the  step  size  parameters  are  set  and  then  checked  to  ensure  the 
integration  time  +  step  size  do  not  exceed  the  end  time.  If  the  step  is 
too  large,  the  step  is  reduced  to  the  integration  interval  and 
integration  continues.  Step  size  segments  are  evaluated  and  then  the 
step  size  is  checked  using  a  similar  computer  epsilon  comparison  as 
previously  discussed.  If  the  step  is  too  small  and  if  at  the  end,  use 
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The  function  concludes  by  checking  the  state  of  the  integration. 

If  at  end  time,  the  function  terminates  and  returns  status  to  PROPAGATE. 
If  the  integration  is  set  to  provide  noise  injection  at  each  step  and 
the  integration  is  at  step  time,  the  function  returns  to  PROPAGATE  for 
noise  injection.  Otherwise  the  function  returns  to  Step  to  continue  the 
integration  until  either  end  time  or  step  time  has  been  reached. 

3 .4  Information  Storage 

The  process  of  storing  data  to  files  for  later  analysis  is  an 
important  feature  of  the  simulation.  As  indicated  earlier  in  this 
chapter,  the  user  is  presented  with  options  with  respect  to  storage  of 
data.  The  user  can  select  whole  state  or  error  state  storage,  or  select 
at  what  rate  the  storage  will  take  place.  Unfortunately,  because  the 
simulation  executes  on  a  PC,  limitations  are  placed  on  storage. 

The  most  limiting  aspect  is  that  DOS  allows  only  a  maximum  of  20 
files  to  be  open  at  any  one  time.  This  doesn't  seem  too  restrictive 
until  one  realizes  that  DOS  uses  five  of  those  files  for  the  operating 
system  and  the  simulation  uses  one  for  the  trajectory  data.  This  leaves 
only  14  files  for  storage  of  data.  Ideally,  it  is  desirable  to  store 
all  the  states  the  simulation  produces.  Because  of  file  limitation, 
only  the  more  "useful"  states  are  stored  to  files. 

An  option  that  was  pursued  to  minimize  this  problem  was  to  store 
multiple  states  in  one  file.  This  was  not  a  viable  option  because  it 
was  considered  that  this  would  make  the  plots  too  busy  and  lead  to  less 
useful  plots. 
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When  the  user  selects  the  states  to  store,  a  preselected  list  of 
states  is  stored  to  disk.  Refer  to  Table  3.1  for  the  applicable 
variables.  The  file  names  under  which  the  states  have  been  stored  have 
also  been  included  in  Table  3.1 

The  other  limiting  aspect  is  storage  capacity.  Unlike  the 
"virtually"  limitless  storage  of  a  mainframe,  a  PC  has  some  more 
realistic  numbers  for  storage.  This  limitation  does  not  present  a  great 
problem  as  long  as  the  user  is  aware  of  his  storage  capacity  and  limits 
the  data  collection  rate  accordingly.  As  a  guideline  for  storage,  a 
three-hour  simulation  using  30-second  collection  intervals,  occupies 
approximately  80K  bytes  of  space 

The  storage  process  is  "hardwired"  in  the  simulation.  If  the  user 
desires  more  flexibility  in  storage  of  data,  the  source  code  has  to  be 
changed  and  recompiled.  However,  the  procedure  as  set  down  should 
handle  most  situations. 

3.5  Programming  Considerations 

In  deciding  how  to  develop  this  simulation,  a  number  of  questions 
needed  to  be  answered.  Foremost  was  the  programming  language  to  be  used 
and  the  system  under  which  the  program  was  going  to  be  developed.  As 
programming  had  already  been  started  (Intermetrics  simulation) ,  the 
obvious  choice  was  to  continue  with  their  process. 

The  selection  of  C  as  the  primary  programming  language  initially 
did  not  appear  to  be  the  best  choice  for  this  simulation.  The  original 
simulation  was  not  very  computationally  intensive.  With  the 
introduction  of  the  propagation  cycle,  the  number  of  computations 
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Table  3.1  States  Stored  to  File 


Error  States 

File  Name 

Whole  States 

File  Name 

5L 

del_lat.dat 

longitude 

long.dat 

51 

del_long.dat 

latitude 

lat . dat 

66z 

wander  angle 

wander . dat 

altitude 

alt. dat 

*y 

phi_Y.dat 

north  velocity 

vel_n.dat 

K 

phi_Z.dat 

east  velocity 

vel_e . dat 

SVX 

vel_N.dat 

vertical 

velocity 

vel_v.dat 

5Vy 

vel_E . dat 

north 

acceleration 

acc_n.dat 

™z 

vel_Z . dat 

east 

acceleration 

acc_e . dat 

6h 

delta_h . dat 

vertical 

acceleration 

acc_y.dat 

6hc 

roll 

roll . dat 

pitch 

pitch.dat 

platform 

azimuth 

azimuth.dat 

increased  100- fold.  Traditionally  FORTRAN  is  a  better  "number  cruncher" 
than  other  languages.  However,  the  simulation  needed  some  bit 
manipulation  techniques  as  well.  C  is  far  better  suited  for  this 
function.  In  addition,  the  simulation  needed  a  good  user  interface  and 
display  screen  manipulation.  Again,  C  is  better  suited  for  these 
capabilities.  The  simulation  is  developed  to  operate  on  a  PC  and  C  is 
quickly  becoming  the  industry  standard  for  PC  programming.  As  C  is 
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reasonably  effective  in  the  area  of  floating  point  computations,  it 
therefore  appeared  that  C  was  the  best  overall  choice. 

C  is  not  without  disadvantages.  One  of  its  biggest  disadvantages 
is  readability.  With  all  its  shorthand  coding  techniques  and  the  use  of 
pointers,  the  program  can  become  very  unreadable  to  a  programmer 
unfamiliar  with  C.  To  avoid  this  problem,  the  programs  are  well 
commented,  including  logical  spacing  of  program  statements.  Another 
area  of  concern,  to  the  structured  programmer  especially,  is  C's 
capability  to  be  unstructured,  namely,  the  promotion  and  demotion 
protocols  for  variables.  C  allows  one  variable  type  to  be  equal  to 
another  variable  type  without  producing  a  compilation  error.  This 
allows  the  program  to  demote  or  promote  a  variable  deliberately.  Care 
must  be  taken  not  to  misuse  this  technique  as  this  can  result  in  data 
corruption  and  loss  of  data  resolution.  This  capability  has  proven  to 
be  valuable  to  the  simulation  program. 

The  previous  program  was  written  in  Microsoft  C.  Microsoft's 
latest  version  of  their  optimizing  C  compiler,  Version  6.0  [20],  has 
been  integrated  to  include  an  editor,  system  BUILD,  and  the  Codeview 
debugger.  Microsoft's  MAKE  utility  has  also  been  made  more  industry - 
compatible.  It  appeared  to  be  the  best  selection  and  through  the 
development  has  proven  to  be  so.  Version  6.0  also  is  closer  to  ANSI  C 
and  assists  in  maintaining  portability.  It  should  be  noted  though  that 
Microsoft  C  still  has  some  non-standard  constructs  that  make  the  program 
difficult  to  move  to  other  systems.  In  the  simulation,  few  of  these 
constructs  are  used  and  small  changes  should  make  this  simulation  very 
portable,  although  this  was  not  one  of  the  goals  of  the  development. 
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The  Intermetrics  program  [1]  was  written  in  Microsoft  C  Version  5.1  and 
some  incompatibilities  were  encountered.  Small  changes  in  the  code  that 
was  borrowed  from  this  earlier  program  solved  these  issues  with  little 
complication. 

The  only  disadvantage  of  utilizing  the  Microsoft  C  compiler  is  the 
lack  of  a  DOS  extender  to  take  full  advantage  of  the  80386  protected 
mode  of  operation  with  the  associated  32-bit  addressing  and  processing. 
The  in-house  WATCOM-386  compiler  [28]  was  an  unacceptable  choice  for 
compiler,  as  problems  were  being  experienced  with  operating  programs  in 
protected  mode.  In  addition,  some  of  the  library  functions  and  syntax 
in  the  Intermetrics  simulation  are  incompatible  with  WATCOM  and  present 
difficulties  in  utilizing  any  of  its  code.  The  goal  was  to  develop  a 
simulation  and  not  be  challenged  with  a  finicky  compiler.  The  only 
option  left  was  to  select  the  286  version  of  Microsoft  C  and  take 
advantage  of  the  compiler  in  other  aspects  such  as  optimization.  The 
downfall  of  this  choice  is  the  loss  of  computation  speed  from  not  fully 
using  the  capabilities  of  the  80386  process. 

The  simulation  is  developed  using  the  compiler's  small  memory 
model.  The  small  model  is  most  applicable  in  this  case  as  the  program 
code  and  data  segments  do  not  exceed  64K  each.  More  importantly,  the 
small  model  only  uses  direct  addressing  where,  the  default  for  variables 
is  NEAR.  This  method  of  addressing  provides  the  fastest  code. 

One  of  the  reasons  that  the  Microsoft  C  compiler  was  selected  was 
its  capability  to  optimize  the  source  code .  All  C  language  source  was 
compiled  with  the  optimizations  listed  in  Table  3.2. 
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Other  compiler  options  include  compiling  under  the  80286  processor 


and  utilizing  in-line  80287  coprocessor  commands.  For  this  version  of 


Table  3.2  Compiler  Optimizations 


Code 

Optimization 

Ot 

enables  optimization  of  code  for  speed  of 
execution 

Oi 

enables  optimization  of  function 
execution 

allows  intrinsic  form  of  function  to  be 
used 

01 

enables  optimization  of  loop  code 
replaces  loop  code  with  more  efficient 
code 

Gs 

removes  stack  checking  code  to  produce 
faster  executing  c ode. 

Microsoft  C,  the  code  only  utilizes  16 -bit  words.  This  obviously  means 
that  the  program  is  not  taking  advantage  of  the  80386  32 -bit  word 
processing.  The  best  this  simulation  can  do  is  take  advantage  of  the 
386  machine  CPU  speed.  In-line  coprocessor  commands  are  the  fastest 
option  available  for  coprocessors.  The  only  disadvantage  of  this 
procedure  is  that,  if  the  machine  used  to  execute  the  simulation  does 
not  have  a  coprocessor,  the  simulation  performance  is  degraded.  Other 
options  allow  the  flexibility  of  switching  between  machines  with  and 
without  coprocessors.  These  option  aren't  quite  as  efficient  and  since 
this  program  requires  a  coprocessor,  dedicated  coprocessor  compilation 
is  used. 
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The  linking  process  involves  using  the  compiler- integrated  BUILD 
process.  All  linkable  modules  are  listed  in  a  program  list  and  the  list 
is  processed  as  a  function  of  the  host  source  code,  in  this  case 
INS_LN94.C.  Link  options  include  command  exepack,  which  removes 
sequences  of  repeated  bytes  in  the  executable  code.  This  optimization 
decreases  the  size  of  code  and  reduces  the  program  load  time.  The 
linker  also  establishes  a  stack  size  of  7K.  Stacks  of  this  size  are  not 
normally  used;  however,  in  this  case  a  large  number  of  global  variables 
and  the  recursion  in  parts  of  the  program  necessitate  a  relatively  large 
stack. 

Chapter  2,  Section  2.5  provides  a  list  of  the  other  software  tools 
used  in  the  simulation  development.  The  assembly  language  programs  are 
assembled  to  object  code  by  Microsoft  Macro  Assembler  Version  5.1  [21]. 
The  C  Utility  Library  [11]  is  linked  with  INS_LN94.C  as  an  additional 
library. 

3.6  Development  Problems  and  Tradeoffs 

It  is  well  known  that  software  development  is  a  time  consuming 
process.  This  simulation  is  no  different.  The  development  stage  took  a 
disproportionate  amount  of  research  time.  It  is  also  well  known  that  a 
program  is  never  at  its  best  level  of  development.  It  can  be  subject  to 
constant  changes  and  updates  as  the  software  is  utilized.  One  could 
spend  the  entire  research  time  in  development  alone. 

To  avoid  this  programming  pitfall,  and  to  leave  sufficient  time 
for  validation,  a  number  of  tradeoffs  were  accepted  for  problems 
encountered  in  the  development.  The  first  problem  was  in  the  trajectory 
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generation  and  data  manipulation  process.  To  make  the  best  use  of  the 
data,  a  spline -fitting  algorithm  is  used  to  produce  data  in  between  the 
points  that  are  generated  by  the  trajectory  generator.  The  algorithm 
proved  to  be  unworkable  in  the  time  frame  provided.  The  alternative 
that  has  been  implemented  is  to  assume  that,  for  a  short  interval,  the 
trajectory  can  be  considered  constant  (the  output  of  a  time -invariant 
model),  and  the  model  is  integrated  over  this  time  interval.  To  do  this 
requires  large  trajectory  data  files  with  data  provided  at  one  second 
intervals.  In  addition,  the  trajectory  must  be  benign  enough  to  allow 
this  assumption  to  hold. 

Problems  were  also  encountered  in  reading  the  unformatted  date 
from  the  trajectory  generators.  The  alternate  method  is  that  INERCA 
[15]  provides  a  report  file  which  is  an  ASCII  file  of  the  trajectory 
data.  This  is  dismantled  by  a  conversion  program  to  generate  the 
appropriate  data.  This  alternative  approach  excludes  the  use  of  PROFGEN 
[2]  as  a  trajectory  generator.  Add  to  this  the  limitation  that  INERCA 
cannot  provide  roll,  pitch,  or  yaw  trajectory  data. 

The  consequence  of  these  problems  and  resulting  tradeoffs  is  that 
the  Litton  fighter  profile  is  not  implemented.  The  interface  for  the 
profile  is  maintained  in  the  program  as  described  up  to  this  point,  and 
all  the  conditions  of  operation  still  remain  valid.  This  trajectory  is 
unselectable  until  further  development  is  performed.  Chapter  4,  the 
simulation  validation,  does  not  address  the  fighter  profile  at  all. 

The  last  problem  in  the  development  stage  is  the  concept  of  real¬ 
time  processing.  The  simulation  processes  the  static  trajectory  in  real 
time  while  the  straight-and-level  trajectory  operates  almost  in  real 
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time,  losirg  approximately  two  seconds  for  every  30  minutes  of 
operation.  Further  development  of  the  propagation  module  in  terms  of 
efficiency  and/or  assembly  language  programming  should  solve  this 
problem. 

It  should  be  noted,  for  clarification,  that  the  real-time  losses 
are  a  measure  of  the  difference  in  the  simulation  clock  as  compared  to 
the  system  clock  that  is  used  for  debugging  the  simulation  and  measuring 
real  time.  The  simulation  clock  is  dependent  on  program  performance  to 
maintain  the  simulation  time  as  close  to  the  system  clock  as  possible. 
The  system  clock  is  developed  directly  form  the  timing  pulses  of  the 
computer  clock.  Refer  to  the  discussion  of  function  Update,  in  Appendix 
E,  for  details  on  this  system  clock. 

3.7  Trajectory  Generation 

As  a  result  of  the  problems  outlined  in  the  previous  section,  only 
one  flight  trajectory  is  generated  for  the  simulation.  The  profile  is 
referred  to  as  a  straight-and-level  profile.  In  fact  this  name  is 
slightly  misleading  in  that  the  trajectory  follows  a  great  circle  route. 
This  allows  changes  in  navigation  parameters  without  being  too  dynamic. 

A  constant  altitude  of  5000  ft  and  a  constant  velocity  of  586  ft/sec  are 
maintained  for  the  duration  of  the  flight.  The  trajectory  starts  at  N 
45  degrees  latitude  and  W  84  degrees  longitude.  The  flight  is  generated 
for  six  hours  of  operation,  although  for  validation  purposes,  the  flight 
is  only  two  hours  in  duration,  as  the  accuracy  specifications  are  for 
two-hour  flights. 
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The  trajectory  data  is  stored  in  file,  straight . trj .  This  file 
must  be  stored  in  the  same  directory  that  the  simulation  stores  data  so 
the  simulation  can  access  the  data  from  them. 

3.8  Stannary 

This  chapter  gives  the  reader  some  insight  into  the  development  of 
the  simulation,  INS_LN94.  The  discussion  is  limited  to  the  two  main 
processes  in  the  program,  function  MAIN  and  function  PROPAGATE.  These 
functions  are  the  key  to  the  simulation.  MAIN  provides  the  simulation 
control  while  PROPAGATE  is  the  function  which  controls  the  integration 
of  the  error  model.  Within  PROPAGATE  is  the  function  INTEGRATE  which  is 
treated  in  some  detail  in  Section  3.3.1  of  this  chapter.  It  provides 
the  means  of  integrating  the  model  forward  in  time.  Appendix  D  provides 
flow  charts  of  these  functions. 

The  simulation  was  developed  using  the  Microsoft  C  Optimizing 
Compiler  Ver  6.0  [20]  and  the  program  is  optimized  using  parameters 
listed  in  Table  3.2.  The  compiler  does  not  take  advantage  of  the 
80386's  32-bit  processing,  but  for  reasons  outlined  in  Section  3.5, 
this  compiler  proved  to  be  the  best  choice. 

Section  3.6  outlines  a  number  of  problems  encountered  during  the 
development  of  the  simulation.  The  problems  impose  the  restriction  that 
the  fighter  profile  is  not  useable  at  this  time.  Further  development 
should  solve  this  problem. 

Information  may  be  stored  for  later  analysis  using  the  simulation 
interface  to  select  the  appropriate  information.  Table  3.1  outlines  the 
information  that  may  be  stored.  Whole  states  or  error  states  may  be 
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tracked  and  stored  and  a  plotting  routine  called  EZPLOT  may  be  utilized 
to  view  data. 

The  reader  is  referred  to  Appendix  E  for  a  description  of  all  the 
simulation  functions  and  to  Appendix  F  for  simulation  user  operating 
procedures . 
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IV.  Simulation  Validation 


The  simulation  is  of  little  use  if  it  is  not  validated  to  assess 
its  accuracy  in  emulating  the  LN-94  INS.  In  this  chapter  the  issues 
related  to  validating  the  model  and  the  simulation  operation  are 
outlined.  The  validation  process  is  completed  in  three  steps.  The  first 
step  is  to  analyze  the  performance  of  the  23 -state  model  used  in  the 
simulation.  There  are  certain  assumptions  made  about  the  23-state 
model,  so  this  step  in  the  validation  process  provides  a  check  of  the 
proper  implementation  of  the  model  rather  than  the  appropriateness  of 
the  model. 

The  second  step  is  to  compare  the  performance  of  the  simulation 
against  the  outputs  of  an  actual  LN-94  INS  in  static  navigation,  and  to 
simulate  a  flight.  This  step  provides  the  most  concrete  measure  of  the 
fidelity  of  the  simulation.  This  process  shows  how  closely  the 
simulation  emulates  the  operation  of  an  actual  INS,  and  how  well  the 
simulation  follows  a  true  trajectory. 

The  final  step  is  to  check  the  performance  of  the  noise  generation 
process.  This  process  involves  analysis  of  the  random  number  statistics 
and  the  general  behavior  of  the  noise  produced  by  the  stochastic  white 
noise  generator  function  NOISE.  Refer  to  Appendix  E  details  on  this 
function . 

This  chapter  explains  the  validation  process  as  described  above. 
Procedures  are  outlined  and  conditions  of  the  validation  are  presented. 
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Data  resulting  from  this  process  is  presented  in  applicable  Appendices, 
and  a  discussion  of  the  results  is  provided. 

4.1  Model  Validation 

As  noted  in  Chapter  1,  the  purpose  of  this  research  is  to 
implement  a  proven  model  of  the  LN-94  into  the  simulation.  As  such, 
this  means  finding  a  reduced-order  model  of  the  LN-94  that  has  undergone 
sufficient  validation  to  be  considered  a  valid  model.  Through 
consultation  with  various  people  doing  on-going  research  in  this  field, 
specifically  Stacey  and  Paschall  [23,27],  the  decision  was  made  to 
develop  the  simulation  based  on  a  23 -state  model  which  had  been 
validated  by  Stacey  during  his  research  [26].  Stacey’s  validation 
process  included  a  comparison  of  a  number  of  simulation  runs  on  MSOFE 
[10]  against  the  results  of  the  full  93-state  Litton  model.  It  was 
decided  that  the  fidelity  of  Stacey's  model  was  sufficient  to  use  in 
this  simulation. 

One  type  of  validation  necessary  for  this  model  is  to  ensure  the 
appropriate  behavior  of  the  model  under  various  conditions  of  gyro  and 
accelerometer  error  for  the  static  navig.  "ion  case.  This  validation  is 
necessary  since  the  model  is  programmed  in  a  different  language  and  is 
executed  within  a  different  operating  environment.  This  validation  is 
also  required  to  ensure  the  integration  technique  is  functioning 
properly . 

The  baseline  information  used  in  this  validation  is  the  unified 
analysis  done  by  Britting  [8],  Britting  analyzes  the  behavior  of  a  9- 
state  INS  error  model  when  gyro  drift  or  accelerometer  bias  is  applied 
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to  the  north,  east,  or  down  axis.  An  exact  correlation  between 
Britting's  results  and  the  results  of  this  model  is  not  possible,  but 
general  characteristic  behavior  is  identified.  It  is  important  to  note 
that  Britting's  analysis  only  considers  a  two-accelerometer  local  level 
system  while  the  Litton  model  is  a  three -accelerometer  system.  The 
result  is  no  vertical  channel  components  that  affect  the  LN-94  model 
have  any  effect  on  the  Britting  model. 

To  perform  this  validation,  the  propagation  module  of  the 
simulation  is  executed.  The  module  is  coded  identically  to  the 
simulation  propagation  process  except  that  there  are  no  real-time 
considerations.  The  module  tracks  error  states  while  integrating 
forward  in  time  over  a  designated  time  interval.  Noise  is  not 
introduced  into  the  model  during  integration.  This  is  to  ensure  the 
same  conditions  as  the  Britting  analysis.  The  trajectory  data  used 
matches  the  Britting  analysis  with  longitude  set  to  zero  degrees,  the 
latitude  set  to  45  degrees,  and  the  gravity  acceleration  set  to  one  g. 
All  other  trajectory  data  values  are  set  to  zero.  Data  is  collected 
every  30  seconds  over  a  simulated  36  hour  time  frame.  All  initial 
conditions  are  zero.  The  bias  or  drift  of  interest  is  applied  at  a 
constant  value  of  one  meru  (milli-earth-rate  unit,  .015  deg/hr)  of  gyro 
drift  or  10"'1  g  for  accelerometer  bias.  The  analysis  looks  at  latitude, 
longitude,  and  attitude  errors  for  a  given  gyro  drift  or  accelerometer 
bias  . 

Another  difference  between  the  Britting  analysis  and  the  LN-94 
implementation  is  that  the  LN-94  coordinate  system  is  implemented  in  the 
East -North-Up  convention,  while  the  Britting  convention  is  North-East- 
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Down.  The  transformation  between  the  LN-94  convention  and  the  Britting 
convention  is: 
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This  presents  some  complications  when  making  comparisons.  Without 
explicitly  deriving  Britting' s  equations  in  the  ENU  convention,  it  can 
be  seen  that  this  transformation  changes  some  sign  conventions  in 
Britting’ s  dynamic  matrix  and  also  switch  sensitive  axes  uncertainties. 
This  difference  in  convention  means  that  for  analysis  4>x  equates  to  eE, 

<f> y  to  € ,  and  to  -€q. 

Appendix  G  shows  the  results  of  the  23-state  model  validation. 

One  of  the  obvious  features  of  the  simulation  results  is  the  magnitude 
of  the  error.  In  all  cases  except  for  <j>z,  the  magnitude  of  the  error  is 
on  the  order  of  10  times  greater  than  that  found  in  the  Britting 
results.  This  increase  in  magnitude  has  even  elevated  magnitudes  of 
error  in  the  azimuth  gyro  drift  case  to  readable  levels. 

This  difference  is  significant  and  would  lead  one  to  question  the 
validity  of  this  comparison.  Keeping  in  mind  the  intent  of  this  part  of 
the  validation  process,  and  after  examining  the  performance  of  the 
simulation  in  the  other  validation  processes,  this  magnitude  difference 
may  be  overlooked  at  this  stage.  Refer  to  Section  5.2  for  further 
discussion  of  simulation  validation. 

It  is  likely  that  part  of  this  difference  is  due  to  error  model 
definition.  If  a  detailed  term-by-term  comparison  of  each  error 
equation  is  performed,  though  this  is  not  done  for  this  document,  it 
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shows  inclusion  of  terms  in  the  LN-94  model  that  are  not  present  in  the 
Britting  model.  Most  evident,  as  mentioned  previously,  is  the  inclusion 
of  the  vertical  errors  in  the  position  and  attitude  equations  of  the  LN- 
94. 

From  a  modal  point  of  view,  simulation  results  are  consistent  with 
Britting  results.  For  gyro  drift,  Foucault  modulation  occurs  as  a  first 
order  influence  in  level  alignment  errors,  Figures  G.6-G.7,  G.11-G.12, 
and  G.16-G.17.  As  expected,  it  is  a  second  order  influence  on  latitude, 
longitude,  and  azimuth  errors,  as  seen  in  Figures  G.4-G.5,  G.8,  G.10- 
G.ll,  G.13-G.15,  and  G.18.  A  Foucault  frequency  of  34  hours  (consistent 
with  45  degrees  latitude)  is  apparent,  as  is  the  84-minute  Schuler 
period.  For  the  accelerometer  bias  plots,  again  the  modes  are 
consistent.  The  Schuler  mode  is  dominant  and  the  same  34-hour  Foucault 
frequency  is  evident,  as  in  Figures  G.21-G.24  and  G.26-G.29.  Due  to  the 
type  of  implementation  that  Britting  presents,  the  vertical 
accelerometer  is  not  plotted. 

In  both  the  gyro  drift  case  and  the  accelerometer  bias  case,  <f>z 
does  not  respond  in  the  same  fashion  as  in  the  Britting  analysis.  Note 
that  the  error  magnitude  of  4>z  for  accelerometer  bias  for  the  simulation 
is  considered  to  be  zero,  Figures  G.25  and  G.30.  What  is  plotted  is  at 
the  noise  level  and  considered  inconsequential. 

Errors  in  the  vertical  axis  are  unstable.  Again,  this  difference 
is  directly  related  to  the  inclusion  of  the  vertical  channel.  This 
difference  is  also  attributed  to  the  fact  that  the  vertical  axis  is 
uncommanded,  as  the  LN-94  is  a  wander  azimuth  implementation. 
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It  is  seen  from  the  results  that  the  error  model  exhibits  the 
proper  modal  behavior.  Performance  of  the  23 -state  model  indicates  with 
some  confidence  that  the  model  and  the  associated  C  language  coding 
performs  well  in  the  simulation.  The  integration  technique  performs  as 
expected.  Although  this  is  not  a  complete  validation,  it  does  provide 
the  necessary  insight  into  the  operation  of  the  model  and  the 
integration  technique  to  be  able  to  proceed  with  the  simulation 
validation. 

4.2  Simulation  Validation 

To  validate  the  LN-94  simulation,  the  ultimate  test  is  a 
comparison  of  data  generated  by  the  simulation  and  data  generated  by  an 
actual  INS.  For  this  validation,  no  actual  flight  data  is  available; 
however,  a  static  navigation  data  set  is  generated  and  is  used  for  this 
validation  process.  The  validation  also  includes  analysis  of  a 
simulated  straight-and- level  flight  trajectory. 

4 .2.1  Accuracy  Considerations .  To  evaluate  the  performance  of 
the  simulation,  accuracy  benchmarks  must  be  established.  FNU  83-1  [3] 
specifies  the  accuracy  requirements  for  the  LN-94.  Table  4.1  summarizes 
the  accuracy  limits  of  interest.  These  accuracies  are  based  on  a  two- 
hour  flight  so  any  comparisons  are  made  up  to  and  including  the  two-hour 
point  on  plots. 

Present  position  accuracy  is  measured  in  terms  of  CEP  or  circular 
error  probable.  CEP  is  a  measure  of  the  probability  that  the  indicated 
present  position  will  be  within  a  specified  radius  of  the  true  position. 
CEP  is  defined  as : 
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Table  4.1  LN-94  Navigation  Accuracy  Limits 


Navigation  Parameter 

Accuracy  (4  min  GC  Align) 

present  position  lat  and  long 

0.6  nm/hr  (cep)  2  hour  fit 

V„,  VEf  V0 

±2.5  ft/sec 

wander  angle 

±0.033  deg  (5.76e-4  rad) 

pitch 

±0.033  deg  (5.76e-4  rad) 

roll 

±0.033  deg  (5.76e-4  rad) 

platform  azimuth 

±0.05  deg  (8.73e-4  rad) 

An  ,  AE ,  A0 

±0.5  ft/sec2 

altitude 

150  ft 

CEP  =0.83 


M 


E  iRERn)2 

Dml _ 

N 


(73) 


N  is  the  number  of  missions  and  RER„  is  the  radial  error  rate  on  the  n- 
th  mission,  which  for  terminal  informatien,  is  the  difference  between 
the  actual  position  and  the  indicated  position  for  the  period  of  the 
flight. 

The  measure  of  a  good  INS  is  its  capability  to  track  a  true 
trajectory.  In  the  case  of  a  flight  this  is  easy  enough  to  measure  as 
the  difference  between  the  true  and  the  indicated  trajectory.  The 
actual  INS  static  case  is  somewhat  different.  The  actual  environment  is 
not  reproduced  exactly  in  the  simulation.  A  model  does  not  precisely 
follow  the  actual  piece  of  equipment.  Models  are  by  definition 
approximations  to  some  degree.  Typically,  high  frequency  influences  are 
not  taken  into  consideration  and  therefore  do  not  impact  on  the  model. 
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In  addition,  in  the  static  navigation  case  is  the  fact  that  the 
specific  force  information  is  not  be  modelled  in  the  INS  truth  model. 

It  is  required  as  an  input.  This  is  a  problem  if  the  INS  environment  is 
uncontrolled.  Environmental  vibrations  are  a  minor  concern  in  that  they 
cannot  be  isolated  and  are  not  realistically  simulated  for  this  thesis. 
This  results  in  unpredicted  specific  force  influences  on  the  INS. 

As  a  result,  there  is  no  true  trajectory  for  the  INS  other  than 
the  fact  that  it  theoretically  should  be  reporting  its  position  as 
standing  still.  This  makes  accuracy  measurement  somewhat  arbitrary. 

The  accu“acy  benchmarks  must  be  set  by  the  developers.  After  some 
discussion  and  application  of  engineering  judgment  it  is  decided,  for 
this  study,  that  the  static  navigation  simulation  must  maintain  present 
position  latitude  and  longitude  within  ±1%  of  the  actual  INS  position 
and  exhibit  the  same  characteristic  behavior.  All  other  states  of 
interest  must  exhibit  the  same  behavior  as  their  actual  INS 
counterparts . 

The  criteria  of  Table  4.1  is  used  for  both  the  simulated  static 
navigation  case  and  the  simulated  flight.  For  both  cases,  the  accuracy 
criteria  are  applied  with  respect  to  the  true  trajectory. 

4.2.?  Data  Collection.  Data  for  static  navigation  is  collected 
from  the  LN-94  in  the  AFIT  Navigation  Lab.  Using  the  1553B  bus 
controller,  the  INS  is  aligned  at  the  AFIT  latitude  and  longitude,  N  39 
degrees  46.925  minutes  and  W  84  degrees  4.992  minutes.  After  alignment, 
the  INS  is  set  to  NAV  mode  for  a  three -hour  navigation  session.  A 
three-hour  collection  is  made  to  look  at  behavior  beyond  the  usual  two- 


hour  limit.  Data  is  collected  from  the  MILSTD  1553B  bus  every  30 


seconds . 

The  method  of  collection  is  an  in-house  program  executed  on 
NAVSTAR,  which  samples  the  bus  data  and  converts  designated  words  of 
data  into  decimal  format  and  stores  them  to  file.  A  conversion  program 
was  written  to  make  the  data  usable  with  the  plotting  routines  used  in 
this  thesis. 

A  similar  approach  is  taken  with  the  simulation.  The  initial 
position  is  set  by  the  MILSTD  1553B  through  the  bus  controller  to  the 
same  position  as  the  actual  INS.  The  initial  state  vector  is  declared 


Table  4.2  Initial  State  Vector 


State 

Value 

State 

Value 

6x: 

0.0 

«x13 

0.0 

6xz 

0.0 

6xj* 

9 . 696391e-9 

6x3 

0.0 

5Xi5 

9 . 696391e-9 

6x4, 

1.084e-5  rad 

$x16 

9 . 696391e-9 

6x5 

1.084e-5  rad 

fiXi? 

6.43972e-5  ft/s 

6x6 

5.8178e-4  rad 

5x18 

6.43972e-5  ft/s 

5x7 

0.0 

5x19 

6.43972e-5  ft/s 

Sx8 

0.0 

6x20 

2 . 424071e- 5 

5x9 

0.0 

6x21 

2.424071e-5 

6x10 

0.0 

6x22 

0.0 

6xn 

0.0 

6x23 

2.236  ft 

6x12 

0.0 

as  per  Table  4.2.  Selection  of  these  initial  conditions  is  a  result  of 
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examining  the  returns  from  an  MSOFE  simulated  alignment  [10,27],  The  la 
values  provided  in  the  Litton  CDRL  [17]  do  not  necessarily  represent  the 
typical  alignment  values  of  the  INS.  It  was  necessary  to  examine  the 
results  of  an  INS  alignment  to  ascertain  the  values  one  might  expect  to 
see  after  an  INS  has  aligned  itself. 

A  number  of  initial  conditions  were  attempted,  but  they  gave 
erratic  behavior  or  large  error  propagation.  The  conditions  outlined  in 
Table  4.2  provided  the  best  performance  and  are  substantiated  by  the 
validation  results.  The  initial  conditions  are  coded  into  the 
simulation  and  for  all  cases  the  simulation  starts  with  these  values. 

The  simulation  does  not  actually  perform  an  alignment.  A  timing  loop  is 
executed  and  these  conditions  are  set. 

The  simulation  software  is  initialized  to  inject  noise  into  the 
model  at  the  end  of  each  step.  The  maximum  step  size  is  set  to  one 
second  and  the  minimum  step  size  is  set  to  10'20  seconds.  Error 
tolerance  is  set  to  10'*.  These  parameters  are  not  particularly 
critical  for  stationary  navigation.  The  navigation  is  benign  in  nature 
and  step  size  does  not  change  and  errors  are  minimal.  These  parameters 
become  more  important  as  the  dynamics  of  the  flight  increase  and  become 
variable . 

Trajectory  data  for  the  static  case  include  present  position 
latitude  and  longitude,  vertical  acceleration  equal  to  one  g,  and  a 
wander  angle  of  -1.588054  radians.  All  other  parameters  are  set  to 
zero.  The  wander  angle  is  included  in  the  trajectory  data,  as  it 
reflects  the  wander  angle  to  which  the  actual  INS  aligns. 
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The  simulation  is  set  for  a  three -hour  navigation  session  and  NAV 
mode  is  selected.  The  data  from  the  simulation  is  collected  every  30 
seconds .  It  should  be  noted  that  the  data  is  collected  from  the 
solution  of  the  integration  routine  just  prior  to  formatting  for  the 
MILSTD  1553B.  This  differs  from  the  data  collection  procedure  for  the 
actual  INS.  Data  is  collected  directly  from  the  1553B  bus.  This 
difference  is  necessary  to  reduce  the  computational  load  on  the 
simulation.  Otherwise  data  would  have  to  be  converted  back  into  decimal 
form  prior  to  analysis. 

The  bus  words  have  a  limited  resolution,  while  the  simulation  data 
is  a  double  precision  floating  point  value.  This  is  worth  noting  but 
does  not  present  any  great  difficulties.  Data  is  collected  for  the 
parameters  listed  in  Table  4.3.  Plotted  results  of  this  data  are  shown 
in  Apoendix  H  and  a  summary  of  maximum  error  magnitudes  is  provided  in 
Table  4.4. 


Table  4.3  Navigation  Parameters  Collected  for  Comparison 


Navigation  Parameter 

Navigation  Parameter 

present  position  lat  and  long 

pitch 

velocity 

roll 

altitude 

platform  azimuth 

wander  angle 

acceleration 

Data  collected  for  the  simulated  flight  is  the  same  as  for  the 
static  flight,  with  the  exception  that  the  trajectory  data  is  provided 
by  a  data  file  and  selected  as  described  in  Appendix  F.  Data  is 
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collected  every  30  seconds  for  a  two-hour  period.  Plots  of  data 
collected  are  shown  in  Appendix  I  and  are  analyzed  in  detail  in  Section 
4.2.4. 

4 .2.3  Static  Navigation  Performance  Analysis .  Two  of  the  most 
important  navigation  parameters  are  latitude  and  longitude.  The 
comparison  of  these  parameters  indicates  close  emulation  of  the  LN-94  by 
the  simulation.  The  error  bounds  of  the  simulation  fall  well  within  the 
one  percent  allowable.  Calculations  based  on  the  two-hour  indicated 
position  reveal  a  change  in  position  of  4071.17  feet  or  a  rate  of  0.34 
nm/hr.  This  equates  to  a  CEP  of  0.27,  well  within  the  bounds  of  the  FNU 
85-1  specification  of  2.6  for  a  single  flight. 

Table  4.4  Simulated  Static  Navigation- -  Summary  of  Maximum  Error 
Magnitudes 


Navigation  Parameter 

Maximum  Error  (2 -hr  flight) 

present  position 

4071.17  ft  (0.34  nm/hr) 

altitude 

150  ft 

X  velocity 

0.52  ft/sec 

Y  velocity 

1.4  ft/sec 

Z  velocity 

1  ft/sec 

wander  angle 

2 . 6xl0'5  rad  (0.0014  deg) 

roll 

0 . 0  rad 

pitch 

2xl0"5  rad  (0.0011  deg) 

platform  azimuth 

5 . 0xl0‘*  rad  (0.028  deg) 

Figure  H.3  depicts  the  altitude  behavior  of  the  simulation.  A 
plot  of  the  INS  altitude  is  not  provided,  as  it  is  zero.  This  is  the 
case  as  the  altitude  update  for  the  INS  is  not  provided  as  a  measure  of 
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baro-altimeter  uncertainty  but  is  indicated  as  a  true  value  at  all 
times.  There  is  no  baro-altimeter  model  in  the  actual  INS  installation. 
What  is  shown  in  Figure  H.3  is  the  effects  of  the  simulated  baro- 
altimeter  uncertainty.  The  values  of  ±150  ft  are  quite  reasonable  for  a 
barometric  altimeter  [3,23].  To  achieve  this  result  the  noise  component 
of  fihc  was  reduced  from  the  model  documentation  value  of  33.0  to  4.0. 

Figure  H.4  shows  the  wander  angle  behavior.  The  trend  of  the 
simulation  is  the  same  as  that  of  the  INS,  and  values  again  are  well 
within  the  one  percent  allowable  error.  The  simulated  two -hour  value  of 
the  error  in  wander  angle  is  very  small  and  is  well  within  the  accuracy 
bounds  specified  in  Table  4.1. 

Velocity  behavior  in  the  X  axis  is  very  close  to  the  INS  data. 
Velocity  in  the  Y  direction,  Figure  H.6,  is  the  only  state  that  behaves 
contrary  to  the  actual  INS.  The  difference  error  between  the  INS  and 
simulation  is  quite  large  and  the  growth  of  the  INS  velocity  is 
significant  compared  to  the  simulation  though  within  limits  of  accuracy 
in  Table  4.1.  Some  of  the  growth  may  be  explained  by  the  real 
environment  of  the  INS  versus  simulated  environment.  Velocity  in  the  Z 
direction  is  consistent  with  the  baro-altimeter.  Recall  that,  for  the 
INS,  there  is  no  baro  uncertainty.  Accordingly  one  would  expect  the 
vertical  velocity  to  be  zero  relative  to  the  simulation  data.  Again, 
accuracy  criterion  is  met. 

Roll,  pitch,  and  platform  azimuth  show  equally  good  performance, 
although  their  emulation  of  INS  data  is  not  as  close  as  the  other 
parameters  have  been.  Behavior  is  similar  and,  for  the  simulation,  the 
FNTJ  85-1  accuracy  is  being  met. 
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Figure  H.ll  and  Figure  H.12  are  provided  to  highlight  the  previous 
discussion  of  vibration  and  its  effects  on  the  INS  performance.  The 
level  accelerations  are  equal  and  non-zero.  This  is  perceived  as  high 
frequency  vibration  of  the  INS.  Heavy  equipment  next  door  to  the  lab  is 
likely  to  be  the  source.  Based  on  this,  it  is  expected  the  actual  INS 
errors  will  be  greater  in  general  than  the  simulation  errors,  and  they 
are.  It  is  important  to  keep  in  mind  that  the  real  world  of  the  INS  is 
very  difficult  to  reproduce  in  the  simulation. 

Tuning  of  the  simulation  model  proved  to  be  relatively  ineffective 
at  making  the  simulation  match  the  LN-94  simulation  with  the  exception 
of  the  baro-altimeter  uncertainty.  By  tuning  the  baro-altimeter 
uncertainty,  typical  baro-altimeter  behavior  of  ±150  ft  is  achieved. 

4.2.4  Flight  Simulation.  The  simulated  flight  validation  looks 
at  the  results  from  the  point  of  view  of  the  limits  set  in  Table  4.1. 

If  the  simulation  can  follow  the  true  trajectory  within  these  limits, 
then  the  simulation  is  considered  valid.  The  simulation  is  validated 
with  a  straight-and- level  trajectory  only. 

The  straight-and-level  profile  is  along  a  great  circle  route  to 
highlight  some  of  the  operating  characteristics  of  the  INS  for  teaching 
and  research  purposes.  The  setup  and  data  collection  is  as  defined 
previously.  Appendix  I  provides  results  of  the  simulation  compared  to 
the  true  trajectory.  Appendix  J  provides  plots  of  the  error  magnitudes 
of  the  simulation  as  compared  to  the  true  trajectory  and  Table  4.5  shows 
these  errors  in  tabular  form. 

Results  of  the  validation  are  excellent.  Figure  J.l  and 
Figure  J.2  provide  the  magnitude  of  error  in  present  position.  From 
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Table  4.5  Simulated  Straight -and- Level  Trajectory- -Summary  of  Maximum 
Error  Magnitudes 


Navigation  Parameter 

Maximum  Error  (2 -hr  flight) 

present  position 

5325.19  ft  (0.44  nm/hr) 

altitude 

160  ft 

north  velocity 

1.95  ft/sec 

east  velocity 

0.65  ft/sec 

vertical  velocity 

1.16  ft/sec 

north  acceleration 

6xl0‘5  ft/sec2 

east  acceleration 

6xl0'5  ft/sec2 

vertical  acceleration 

6xl0~5  ft/sec2 

wander  angle 

0.007  deg 

roll 

0.00104  deg 

pitch 

0.0022  deg 

platform  azimuth 

0.0333  deg 

these  '"=lues,  the  indicated  position  after  two  hours  is  5325.19  ft  from 
the  true  position  with  an  RER  of  0.44  nm/hr.  This  provides  a  CEP  of 
0.37.  Present  position  errors  are  well  within  the  accuracy  parameters 
of  Table  4.1. 

Altitude  behaves  as  predicted  in  the  static  simulation  case.  The 
baro- altimeter  uncertainty  drives  the  altitude  state  to  errors  within 
the  150  ft  accuracy  limit.  Velocities  display  the  characteristic 
sinusoidal  behavior  and  are  limited  to  magnitudes  of  less  than  2.0 
ft/sec,  as  seen  in  Figure  J.4  to  Figure  J.6. 

The  magnitudes  of  acceleration  in  the  north  and  east  directions, 
as  depicted  in  Figure  1.7  and  Figure  1.8,  are  very  small.  As  a  result, 
the  initial  conditions  influence  the  error  behavior  more  than  expected. 
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Over  time  the  initial  condition  influence  is  reduced  and  the  simulation 


follows  the  true  trajectory  extreme^  closely.  As  acceleration 
magnitude  increases  to  more  typical  levels  as  in  the  vertical 
acceleration,  Figure  1.9,  the  effects  of  initial  conditions  become 
insignificant . 

Roll  and  pitch  error  behavior,  as  seen  in  Figures  J.ll  and  J.12, 
are  within  accuracy  limits.  The  only  parameter  that  falls  outside  the 
accuracy  limits  is  platform  azimuth,  portrayed  in  Figure  J.13.  The 
azimuth  error  starts  outside  the  limits  and  over  time  starts  to  move 
towards  the  uae  trajectory.  This  leads  one  to  believe  that  the  initial 
conditions  may  be  impacting  on  this  parameter.  Platform  azimuth  is  a 
function  of  the  solution  to  4>z.  The  initial  condition  for  this  state  is 
set  well  below  the  la  value  designated  in  the  Litton  CDRL  and  is 
consistent  with  values  for  an  INS  alignment.  The  error  in  platform 
azimuth  is  just  outside  the  limits  of  the  FNII  85-1  specification 
(Table  4.1)  and  is  considered  reasonable  without  any  further  data  for 
comparison . 

In  all  cases,  the  simulation  performs  extremely  well  in  emulating 
an  INS  and  in  staying  within  the  accuracies  expected  of  the  LN-94.  Very 
little  tuning  of  the  model  was  required  to  achieve  this  accuracy.  A 
case  can  probably  be  made  for  increasing  the  values  of  the  noise 
strength  in  the  model  to  better  emulate  the  "inaccuracies"  of  the  LN-94. 
This  would  introduce  higher  levels  of  uncertainty  into  the  noise  process 
and  induce  greater  magnitudes  of  error  in  the  model.  To  do  this 
realistically,  flight  data  for  the  performance  of  the  LN-94  would  be 
required.  States  dealing  with  accelerometer  and  gyro  uncertainties 
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would  be  ideal  candidates  for  this  treatment,  but  again  with  no  baseline 
data  for  comparison,  the  attempt  to  emulate  the  exact  accuracy  of  the 
LN-94  would  be  futile.  The  ability  to  stay  within  the  LN-94  accuracies 
is  sufficient  substantiation  to  consider  the  simulation  valid. 

A  case  can  also  be  made  for  increasing  the  number  of  states  in  the 
model.  Rather  than  relying  on  noise  parameters  to  produce  the 
additional  errors,  some  of  the  errors  that  are  lost  in  the  model 
reduction  can  be  reintroduced  to  the  model. 

4 .3  Pnisf*  Proems*  Validation 

The  method  of  generating  the  Gaussian  white  noise  w.ich  provides 
the  randomness  of  the  model  process  is  a  critical  one.  As  is  discussed 
in  Chapter  2,  the  stochastic  process  must  have  statistics  of  N[0,Qd]. 

The  techniques  used  to  develop  these  statistics  are  discussed  in  some 
detail.  The  one  thing  that  remains  to  consider  is  whether  the  random 
number  generator  provided  as  part  of  the  compiler  can  provide  the  random 
numbers  with  the  appropriate  statistics. 

The  number  generator  must  be  able  to  produce  scalar  numbers  in  a 
Gaussian  distribution  with  statistics  N [ 0 , 1 ] .  The  supplied  generator 
provides  uniform  deviates  between  the  values  zero  and  one.  The  number 
generation  process  involves  summing  twelve  random  numbers  and  then 
subtracting  the  value  6.0  from  the  sum.  The  summing  process  provides 
approximately  Gaussian  characteristics  and  the  subtraction  sets  the  mean 
to  zero. 

Figure  4.1  shows  the  results  of  generating  2500  random  numbers 
from  the  function  Random_Number .  The  sample  size  is  not  significant.  A 
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number  of  different  sample  sizes  ranging  from  50  to  5000  were  evaluated 
All  produced  the  same  kind  of  statistics.  The  typical  Gaussian  shape 
can  be  seen  and  the  statistics  for  this  sample  are  N[ -0 . 011863 , 1 . 01145 ] 


Random  Number  Value 

Figure  4.1  Random  Number  Statistics 


The  deviation  from  the  zero  mean  value  expected  is  acceptable , 
though  further  refinement  could  be  achieved  by  compensating  for  this 
difference  before  the  numbers  are  used  in  the  noise  process.  Despite 
this  difference  in  mean  value,  by  utilizing  numbers  with  these 
<=ratistics ,  one  can  be  confident  in  that  equating  Equation  (71),  the 
appropriate  stochastic  noise  can  be  generated. 

Figure  4.2  shows  an  example  of  the  noise  generated  by  the 
simulation  for  stat"  four  of  the  «t-afp  moad  a  The  *- andemne c c  ot 
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Time  (hours) 

Figure  4.2  Noise  Characteristics  of  State  Four 

the  noise  is  noted  in  the  noise  behavior  and  the  approximately  zero  mean 
value  is  apparent.  The  magnitude  of  the  noise  is  consistent  with  the 
values  expected  for  the  model.  The  selection  of  the  state  is  not 
important  as  analysis  has  shown  that  each  noise  source  is  behaving  in 
comparable  fashion. 

4 . 4  Summary 

This  chapter  discussed  the  validation  of  the  simulation.  The 
results  indicate  that  the  simulation  is  emulating  the  actual  INS 
performance  quite  well.  The  criteria,  to  maintain  less  than  one  percent 
difference  error  between  the  INS  and  the  simu1ation,  is  met  i.,  the  rase 
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of  static  navigation.  Environmental  influences  and  higher  order  errors 
can  account  for  differences  between  the  two  sets  of  data.  The 
implementation  of  a  reduced  order  model  in  the  simulation  can  account 
for  some  of  these  differences  as  well.  Some  error  emulation  capability 
is  lost  in  the  reduction.  Appendix  H  summarizes  the  static  navigation 
simulation  as  compared  to  actual  INS  static  navigation  data.  Table  4.4 
displays  maximum  errors  produced  by  the  simulation  for  the  static 
navigation  case. 

Appendix  I  and  Appendix  J  summarize  the  results  of  the  straight- 
and- level  flight  trajectory.  Table  4.5  summarizes  the  maximum  errors 
encountered  in  the  simulation.  The  accuracy  of  the  simulation  can  only 
be  measured  as  a  function  of  the  accuracy  limits  in  Table  4.1.  As  is 
seen  by  the  data  presented,  the  simulation  does  meet  this  benchmark. 
Unfortunately,  without  flight  data  from  the  actual  INS,  tuning  the 
simulation,  as  indicated  in  Section  4.2.4,  is  not  possible.  Validation 
shows  that  the  simulation  is  a  good  emulation  of  the  LN-94  based  on 
benchmarks  that  are  available. 

The  noise  generation  technique  is  discussed  to  validate  its 
performance.  Figure  4.1  indicates  that  the  statistics  of  the  random 
number  generator  are  as  required  and  Figure  4.2  shows  the  typical 
behavior  of  the  noise  injected  into  the  model.  It  can  be  said  with 
confidence  that  the  noise  generation  process  is  performing  as  is 
required. 
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V.  Conclusions  and  Recommendations 


This  chapter  restates  the  major  objectives  of  the  thesis  and 
indicates  to  what  extent  the  objectives  are  met.  The  research  effort  is 
summarized  and  recommendations  anu  future  considerations  are  presented. 

5 . 2  Conclusions 

The  primary  goal  of  this  research  is  to  develop  a  high  fidelity 
simulation  of  the  LN-94  INS  for  use  on  a  personal  computer  in  the  AFIT 
Navigation  Lab.  This  goal  is  achieved.  Some  problems  are  encountered, 
however,  and  are  outlined  as  the  individual  secondary  goals  are 
discussed . 

The  selection  of  a  reduced  order  model  of  the  LN-94  is  one  of  the 
first  tasks  completed  in  the  research.  The  intent  of  the  reduced  order 
model  is  reduction  in  computation  loading.  This  is  imperative  in  a 
simulation  trying  to  achieve  real-time  processing  on  a  PC  class  machine. 
The  answer  was  found  in  research  being  conducted  at  AFIT.  A  23 -state 
LN-94  model  was  developed  but  was  not  implemented  by  Stacey  [23,27]. 
Development  of  this  model  in  this  thesis  is  limited  to  implementation 
within  the  simulation  and  some  tuning  of  noise  processes  to  ensure  a 
match  with  the  actual  INS  operation. 

Validation  of  the  model  using  Britting's  analysis  is  cursory  at 
best,  given  the  differences  in  implementation.  Britting's  data, 
however,  is  presented  in  such  a  way  as  to  make  the  comparison  with 
simulated  data  relatively  easy.  The  characteristics  of  the  23-state 
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model  are  consistent  with  INS  behavior,  and  simulation  results  bear  out 


that  conclusion.  Differences  between  the  LN-94  simulation  and 
Britting's  analysis  are  such  that,  for  future  research,  the  validation 
results  provided  in  this  research  may  be  more  appropriate. 

One  of  the  most  critical  goals  of  the  thesis  is  the  selection  of 
an  integration  technique.  This  technique  is  responsible  for  the 
propagation  of  the  model  over  time  and  model  validity  is  directly 
impacted  by  its  processing  abilities.  The  fifth-order  Kutta-Merson 
technique  is  chosen  based  on  its  ability  to  handle  six-degree-of- 
freedom,  traj ectory- type  integrations  [7],  The  automatic  step  sizing 
algorithm  is  an  added  advantage  to  the  technique. 

Problems  were  encountered  with  the  development  of  a  spline¬ 
fitting  algorithm  for  the  generation  of  trajectory  estimates  between 
data  points.  The  varying  dynamics  of  the  fighter  profile  do  not  permit 
using  fixed  trajectory  points  and  still  achieve  the  necessary  accuracy 
in  the  simulation.  To  obtain  realistic  results,  a  spline- fitting 
algorithm  must  be  implemented.  The  programming  of  this  algorithm  is  not 

I 

achieved  in  this  research.  Errors  in  the  coding  could  not  be  resolved. 
Synchronization  of  data  with  integration  and  the  generation  of  corrupted 
data  proved  to  be  the  greatest  areas  of  concern  and  as  a  result,  the 
fighter  profile  was  not  implemented. 

INERCA  [15]  proves  to  be  a  very  easy  program  to  use  but  is  limited 
in  the  output  data  set  that  it  provides.  This  program  should  be 
expanded  to  include  roll,  pitch,  and  yaw  data  or  be  abandoned  in  favor 
of  PROFGEN  [2], 
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Stochastic  noise  generation  is  discussed  in  some  detail  in  Chapter 
4,  Secti^"  4.3.  The  system  random  number  generator  proves  to  be 
effective.  Sequential  correlation  is  essentially  eliminated  by  using  a 
random  number  to  select  from  a  vector  of  random  numbers.  If  there  is  a 
weakness  in  this  generator  it  is  the  size  of  RAND_MAX  which  in  the  case 
of  PC's  is  32768,  where  RAND_MAX  represents  the  maximum  positive  integer 
type  number  achievable  in  the  16 -bit  environment.  The  consequence  of 
this  is  that,  for  the  large  number  of  random  numbers  required,  it  is 
necessary  to  evaluate  the  same  32768  numbers  n  times,  where  n  is  the 
actual  numbers  required  divided  by  32768.  Admittedly,  the  numbers  are 
somewhat  correlated  by  this  process.  To  achieve  better  results,  a 
different  operating  system  is  required. 

One  of  the  goals  is  to  design  an  effective  user  interface.  The 
user  interface  is  achieved  through  a  character-based,  interactive 
quest ion -and -answer  approach.  Sufficient  information  is  provided  by  a 
program  overview  at  the  beginning  of  the  program,  and  the  questions  are 
fairly  self-explanatory.  The  interface  allows  selection  of  a  trajectory 
type,  type  of  states  to  track  and  store,  and  collection  frequency. 
Plotting  capabilities  are  accessible  through  the  program  interface  and 
are  provided  by  EZPLOT,  an  Air  Force  developed  program.  A  user’s  guide 
is  provided  as  Appendix  F  if  any  questions  arise  concerning  the 
operation  of  the  simulation. 

The  capability  to  communicate  with  the  1553B  bus  is  achieved 
through  the  Ballard  PC1553-2  interface  card  [3],  Formatted  data 
according  to  the  FNU  85-1  [3]  is  produced  by  the  simulation.  The 
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simulation  responds  to  any  one  of  three  command  words;  #1,  #2,  and  #24. 
The  specifications  for  these  command  words  are  provided  in  Appendix  A. 

The  final  goal  is  the  validation  of  the  simulation.  Validation 
results  show  that  INS_LN94  C  is  a  viable  simulation  of  an  actual  LN-94 
INS.  Validation  is  performed  for  a  static  navigation  trajectory  and  a 
straight-and- level  trajectory.  Both  cases  highlight  the  simulation's 
ability  to  emulate  the  LN-94.  There  are  limitations  to  the  validation 
process . 

The  static  navigation  case  is  compared  against  the  data  collected 
from  an  INS  in  an  uncontrolled  environment.  This  results  in  unknown 
influences  on  the  INS  which  are  not  modelled  in  the  simulation. 
Simulation  noise  processes  can  account  for  some  of  these  unknown  inputs 
but  not  all.  Nonetheless,  the  simulation  emulates  the  LN-94  within  ±1% 
for  position  error,  and  behavior  of  all  navigation  parameters  is 
similar . 

The  straight-and-level  simulation  tracks  the  true  trajectory  very 
well.  Some  might  say  too  well.  Without  specific  flight  data  to  compare 
against,  the  accuracy  of  the  simulation  is  based  on  the  FNU  85-1 
accuracy  specifications.  The  simulation  meets  all  the  specifications 
but  the  question  that  arises  is,  ’’Did  the  simulation  meet  them  too  well 
or  not  well  enough?"  The  flight  data  can  show  precisely  how  the  LN-94 
tracks  a  trajectory  of  this  type.  An  INS  of  this  caliber  should  follow 
the  true  trajectory  very  closely.  A  good  flight  data  set  would  prove 
beneficial  to  the  validation  process. 
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5 . 2  Reconmendat ions 


Tne  production  of  an  INS  simulation  is  the  primary  goal  in  this 
thesis  and  the  degree  of  its  fidelity  is  a  measure  of  the  success  of  th» 
thesis.  It  is  an  excellent  tool  in  which  to  exercise  the  knowledge 
acquired  during  the  navigation  sequence  cf  the  masters  program. 

However,  that  is  only  one  aspect  of  the  research  effort. 

A  good  portion  of  this  effort  is  in  the  software  devel  pment  of 
these  principles  into  a  cohesive  and  efficient  simulation.  This 
simulation  development  requires  e  substantial  amount  of  programming:  on 
the  order  of  5000  lines.  It  requires  a  broad  knowledge  in  programming 
techniques  in  both  higher  level  language  and  assembly  language.  A  good 
working  knowledge  of  the  personal  computer  and  the  DOS  operating  system 
is  required.  The  molding  of  the  navigation  principles  into  a  software 
package  with  specific  capabilities  is  a  fascinating  experience. 

Continued  research  in  this  area  is  highly  recommended  as  simulation  is 
the  tool  of  the  future. 

It  is  also  recommended  that  the  software  development  that  does  go 
on  as  a  result  of  research  receive  more  attention  in  the  overall 
evaluation  of  the  research  effort.  Emphasis  should  be  put  on  developing 
well  managed,  well  documented,  and  efficient  software  development 
techniques . 

The  process  of  validating  software  is  an  on-going  process.  The 
validation  of  this  software  was  sufficient  to  show  that  the  simulation 
operates  well  as  an  emulation  of  the  LN-94.  However,  given  the 
magnitude  problems  in  the  model  validation  ,  and  the  somewhat 
uncontrolled  environment  of  the  static  navigation  validation,  a  more 
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precise  evaluation  tool  is  required  to  further  substantiate  the  previous 
statement.  It  is  strongly  recommended  that  the  validation  process 
continue  and  an  excellent  tool  for  use  in  further  validation  is  MSOFE 
[10]. 

The  primary  ta^k  should  be  to  evaluate  the  23-state  mouel.  By 
implementing  the  23-state  model  in  MSOFE  on  a  VAX-based  machine  it  is 
possible  to  compare  results  to  ensure  proper  operation  of  the  simulation 
software.  This  comparison  also  presents  an  opportunity  for  more  tuning 
of  the  rnode^.  and  evaluation  of  initial  conditions.  It  is  important  to 
continue  evaluation  of  the  initial  conditions  in  an  effort  to  reduce  the 
phase  differences  that  are  seen  between  the  simulated  data  and  the 
actual  INS  data  of  the  static  navigation  case. 

The  validation  should  first  look  at  the  error  state  behavior  of 
the  model  to  trv  and  identity  why  the  model  is  generating  rror 
magnitudes  10  times  greater  than  the  Bribing  analysis.  When  this 
situation  has  been  clarified,  MSOFE  static  navigation  runs  can  be  used 
to  fine  tune  the  simulation.  This  approach  eliminates  the  unknown 
environment  influences  that  are  present  when  compared  to  actual  INS  data 
and  provides  the  benchmark  needed  to  tune  the  simulation  in  the  static 
navigation  c  .se . 

Another  area  where  MSOFE  may  be  used  to  advantage  is  through  an 
implementation  of  the  23-state  model  in  MSOFE  on  a  PC-class  machine. 
MSOFE  can  propagate  the  truth  model  in  a  similar  fashion  to  the 
simulation,  except  with  no  real-time  considerations.  The  results  can 


provide  a  good  indication  of  simulation  capabilities. 


The  MSOFE  results 


provide  a  benchmark  in  the  PC  environment,  and  therefore,  an  excellent 
tool  for  validation  of  the  simulation  software. 

5.2.1  Future  Research.  The  capabilities  of  a  simulation  are  only 
limited  by  the  creativity  of  the  programmer.  This  simulation  is  no 
exception  as  the  possibilities  for  future  enhancements  are  limitless. 

It  should  form  a  solid  basis  for  continued  simulation  research  leading 
to  an  integrated  navigation  simulation  package  at  the  AFIT  Navigation 
Laboratory . 

In  the  short  term,  refinement  of  the  program  should  be  the  next 
step  in  any  research.  The  first  step  in  refinement  should  come  in  the 
development  of  better  trajectory  data  handling  techniques.  As  this  is 
the  only  area  of  difficulty  in  the  development  stage,  this  should 
receive  attention  first  in  any  continued  research.  A  close  look  at  the 
synchronization  issues  of  a  spline-fitting  algorithm  would  be 
beneficial.  Synchronization  difficulties  and  the  generation  of 
corrupted  data  are  the  main  reasons  this  algorithm  Is  not  implemented. 
With  the  appropriate  amount  of  time,  this  algorithm  can  be  coded  and  its 
inclusion  would  enhance  the  simulation  tremendously  and  allow  for  the 
use  of  highly  dynamic  trajectories. 

Real-time  simulation  is  another  area  which  does  not  achieve  full 
success.  The  static  navigation  case  processes  data  in  real  time  while 
the  straight -and- level  flight  loses  real  time  at  a  rate  of  approximately 
two  seconds  for  every  30  minutes  of  navigation.  Two  approaches  are 
possible  to  solve  this  issue.  The  first  approach  is  to  implement  the 
simulation  to  take  advantage  of  the  386  processing  capabilities.  This 
involves  conversion  of  the  source  code  to  386  compiler  source  code. 
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Recall  the  problems  r-u-uuncered  with  the  WATCOM  compiler,  as  discussed 
in  Chapter  3.  Care  should  be  taken  in  selecting  a  compiler  and 
depending  on  which  compiler  is  used,  this  process  may  be  simple  or 
complex . 

The  second  approach  is  to  take  advantage  of  the  speed  of  assembly 
language .  This  approach  tends  to  be  more  time  consuming  to  implement 
and  in  most  cases  very  difficult  unless  the  programmer  is  very  familiar 
with  assembly  language.  It  also  leads  to  less  maintainable  or 
modifiable  code  in  addition  to  being  difficult  to  document.  The  first 
approach  is  recommended  though  both  are  viable  solutions  to  real-time 
processing 

Expansion  of  the  communications  capabilities  of  the  simulation  is 
another  area  of  refinement.  The  simulation  is  presently  restricted  to 
responding  to  one  input  and  two  output  messages  from  the  1553  hue.  All 
words  are  not  utilized  in  each  case.  Expansion  of  the  data  set  to 
include  all  words  in  these  messages  and  possibly  respond  to  other 
messages  is  a  challenge. 

The  simulation  can  benefit  from  an  alignment  simulation.  The 
alignment  could  be  developed  to  provide  randomized  initial  conditions 
and  the  simulation  could  have  the  capability  to  start  NAV  mode  in 
attitude  ready  or  degraded  NAV  modes  [3].  An  alignment  process  could 
make  the  concept  of  degraded  navigation  meaningful  and  provide  a  better 
teaching  tool.  The  randomized  initial  conditions  could  provide  the 
capability  of  multiple  different  flights  for  analysis  of  data. 

The  integration  of  Kalman  filtering  into  the  simulation  would 
further  enhance  its  capability  to  emulate  the  LN-94.  One  concern, 
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though,  is  to  not  simply  develop  another  MSOFE.  The  challenge  of  real¬ 
time  propagation  and  filtering  would  be  an  excellent  follow-on  research 
effort . 

The  final  goal  of  any  further  research  would  be  to  develop  a  truly 
integrated  navigation  system  simulation  in  the  AFIT  Navigation 
Laboratory.  The  expansion  and  development  of  the  limited  GPS  and  CADC 
simulations  now  present  in  the  laboratory  with  the  INS  simulation 
incorporated  into  one  system  would  provide  an  exceptional  research  and 
learning  tool. 
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Appendix  A:  FNU  85-1  Word  Formats 


This  appendix  provides  a  summary  of  the  information  that  is 
necessary  to  format  the  data  produced  by  the  simulation  for  the  MILSTD 
1553.  The  command  word  specifications  are  supplied  and  the  command  word 
responses  are  outlined.  The  exact  format  of  those  words  used  by  the 
simulation  are  also  provided. 

A.l  Commend  Word  Specifications 

Table  A.l  Command  Word  Specifications 


ID 

ADDR 

R/T 

SUB -ADDR 

CNT 

Comments 

Command  Word 
#1 

05h 

T 

00001 

22 

INU  to  CC 

Command  Word 
#2 

05h 

R 

00010 

4 

CC  to  INU 

Command  Word 
#24 

05h 

T 

11C00 

14 

INU  to  CC 

Note  that  the  word  counts  are  not  the  full  32  words  that  are  displayed 
on  the  simulation  screen.  The  screen  will  only  update  those  words 
specified  in  the  command  word  specification. 
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Table  A. 2  Response  to  Command  Word  #1 


Word  Specification 


Ref  Output 


INU  Status  Word 


Time  Tag  Velocity  (16,17,18) 


Time  Tag  Attitude  (10,11,12,'") 


Time  Tag  Present  Position  (6, 7, 8, 9) 


Baro-Inertial  Altitude 


Present  Position  Latitude  (MSP) 


Present  Position  Latitude  (LSP) 


Present  Position  Longitude  (MSP) 


Present  Position  Longitude  (LSP) 


Pitch 


True  Heading 


Platform  Azimuth 


Wander  Angle 


Magnetic  Heading 


North- South  Velocity 


East-West  Velocity 


Vertical  Velocity 


Ground  Speed 


North-South  Acceleration 


East-West  Acceleration 


Vertical  Acceleration 


Note  that  where  N/A  appears  in  the  Output  column  this  means  that  the 
word  is  not  used  in  the  simulation. 
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Table  A. 3  Response  to  Command  Word  #2 


Word 

Word  Specification 

Ref  Input 

1 

Present  Position  Latitude  (MSP) 

60 

2 

Present  Position  Latitude  (LSP) 

60 

3 

Present  Position  Longitude  (MSP) 

61 

4 

Present  Position  Longitude  (LSP) 

61 

Note  that 
Table  A. 9 


Inputs  60  and  61  are  identical  to  Outputs  14  and  15. 
and  Table  A. 10  for  the  formats. 


Refer  to 
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Table  A. 4  Response  to  Command  Word  #24 


Word 

Word  Specification 

Ref  Output 

1 

INU  Status  Word 

6 

2 

Time  Tag  Body  Rate  (4,5,6) 

99H 

3 

Magnetic  Variation 

N/A 

4 

Roll  Rate 

34 

5 

Pitch  Rate 

33 

6 

Yaw  Rate 

35 

7 

Roll  Angle  Acceleration 

N/A 

8 

Pitch  Angle  Acceleration 

N/A 

9 

Yaw  Angle  Acceleration 

N/A 

10 

Longitudinal  Acceleration 

N/A 

11 

Lateral  Acceleration 

N/A 

12 

Normal  Acceleration 

N/A 

13 

Align  Status 

N/A 

14 

INU  Vendor  Ident 

N/A 

Note  that  an  N/A  in  the  output  column  means  that  the  word  is  not 
applicable  to  the  simulation. 
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Table  A. 5  Roll  and  Pitch  Word  Formats 


Table  A. 6  True  Heading  and  N-S  Velocity  Word  Formats 


Table  A. 7  E-W  and  Vertical  Velocity  Word  Formats 


Table  A.  8  Baro- Inertial  Altitude  and  Time  Tag  Word  Formats 


Output  #13  Baro- 
Inertial  Altitude 


+16,384 


+32,768 


-65,536 


Bit  Value  ft 
Positive  Up  from 
Sea  Level 


Note:  Total  value  is  offset  by  +32,768  ft 

ie.  +50,000  ft  (actual)  is  represented  by  +17,232  ft  (data) 


Table  A. 9  Present  Position  Latitude  Word  Format 


Output  #14  Host 
Significant  Word 


+0.00549316*0625 


+0.010986328125 


+0.02197265625 


+0.04394531250 


+0.08789062500 


+0.17578125000 


+0.35156250000 


+0 . 70312500000 


+1.40625000000 


+2.81250000000 


+5.62500000000 


+11.2500000000 


+22.5000000000 


+45.0000000000 


+90.0000000000 


-180.00000000000 


Output  #14  Least 
Significant  Word 

p 

16 

15 

+8.3819031715e-8 

14 

+1.67638063430«-7 

13 

+3.35276126861e-7 

12 

+6.705522537236-7 

11 

+1 . 3411045074466-6 

10 

+2.6822090148926-6 

9 

+5.364418029785e-6 

8 

+1 . 072883605957e-5 

7 

+2.14576721191416-5 

6 

+4 . 291 534 423828 le- 5 

5 

+8.58306884765656-5 

a 

+1.716613769531256-4 

3 

+3 . 43322753906250e-4 

2 

+6.86645507812500e-4 

III 

+1.37329101562500e-3 

0 

+2.7465820312500e-3 

1  Hi 

IH 

Bit  Value 
Degrees 


Bit  Value  Degrees 
North  Latitude 
Positive 


Table  A. 10  Present  Position  Longitude  Word  Format 


Table  £.11  N-S  and  E-W  Acceleration  Word  Formats 


Note:  When  acceleration  exceeds  range  of  word,  the  output  shall  stay  at 
maximum  until  acceleration  returns  to  within  range. 


Note:  lg  sensed  is  transmitted  as  zero. 
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Table  A. 12  Vertical  Acceleration  and  Wander  Angle  Word  Formats 


Output  #18 
Vertical 
Acceleration 

p 

16 

15 

+0.015625 

14 

+0.03125 

13 

+0.0625 

12 

+0.125 

11 

+0.25 

10 

+0.5 

9 

+1.0 

8 

+2.0 

7 

+4.0 

6 

+8.0 

5 

+16.0 

n 

+32.0 

3 

+64.0 

2 

+128.0 

1 

+256.0 

0 

-512.0 

1 

| 

Bit  Value  ft/s2 
Positive  Up 

Output  #36 
Wander  Angle 

P 

16 

15 

+0.0054931640625 

14 

+0.010986328125 

13 

+0.02197265625 

12 

+0.04394531250 

11 

+0.08789062500 

10 

+0.17578125000 

9 

+0.35156250000 

8 

+0.70312500000 

7 

+1.40625000000 

6 

+2.81250000000 

5 

+5.62500000000 

n 

+11.2500000000 

3 

+22.5000000000 

2 

+45.0000000000 

n 

+90.0000000000 

0 

-180.00000000000 

1 

1 

Bit  Value  Degrees 
Positive  Counter- 
Clockwise  True 
North  to  Y  axis 

Note:  When  acceleration  exceeds  range  of  word,  the  output  shall  stay  at 
maximum  until  acceleration  returns  to  within  range. 

Note:  lg  sensed  is  transmitted  as  zero. 
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Table  A. 13  Platform  Azimuth  and  INS  Status  Word  Formats 


Output  #104 
Platform  Azimuth 

p 

16 

n 

+0.0054931640625 

14 

+0.010986328125 

13 

+0.02197265625 

12 

+0.04394531250 

11 

+0.08789062500 

10 

+0.17578125000 

9 

+0.35156250000 

8 

+0.70312500000 

■ 

+1.40625000000 

6 

+2.81250000000 

5 

+5.62500000000 

■ 

+11.2500000000 

3 

+22.5000000000 

2 

+45.0000000000 

1 

+90.0000000000 

0 

-180.00000000000 

■ 

Bit  Value  Degrees 
Positive  Clockwise 
from  Y  axis 

Output  #6  INS 
Status  Word 

P 

16 

15 

Holding  Brake 
Select 

14 

Operational  Mode 

13 

Operational  Mode 

12 

Operational  Mode 

11 

Align  Hold 

10 

Taxi  Hold 

9 

Kalman  Update 
Reject 

8 

Kalman  Update 
Complete 

■ 

Filter  Background 
Busy 

6 

Degraded  Nav 

5 

Bit  Acknowledge 

■ 

Baro-Inertial 
Altitude  Valid 

3 

Time  Tag  Valid 

2 

Battery  Valid 

D 

Attitude  Valid 

0 

INU  Valid 

■ 

Note:  Op  Mode  (bit  12, 13, 14) --0  0  0  STANDBY,  001  NAV,  0  1  0  GC  Align 
0  1  SH  Align,  101  INFLIGHT  Align 
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Appendix  B:  LN-94  Truth  Model  Definition 


This  appendix  provides  an  overview  of  the  93 -state  error  model 
defined  in  the  Litton  CDRL  [17]. 

Table  B.l  INS  Truth  Error  Model  Partition  (5xx 


State 


Name 

Definition 

S6X 

x  component  of  position  error- true 
to  computer  frame 

SBy 

y  component  of  position  error-true 
to  computer  frame 

sez 

z  component  of  position  error- true 
to  computer  frame 

K 

x  component  of  platform  tilt 
error-true  to  platform  frame 

*y 

y  component  of  platform  tilt 
error- true  to  platform  frame 

4>z 

z  component  of  platform  tilt 
error- true  to  platform  frame 

6VX 

x  component  of  error  in 
computed  velocity 

6Vy 

y  component  of  error  in 
computed  velocity 

6VZ 

z  component  of  error  in 
computed  velocity 

Sh 

error  in  vehicle  altitude 
above  reference  ellipsoid 

ShL 

error  in  lagged  inertial 
altitude 

&  s3 

error  in  vertical  channel 

6  SA 

error  in  vertical  channel 
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Table  B.2  INS  Truth  Error  Model  Partition  Sx2 


State 

Name 

Definition 

14 

b,c 

x  component  of  gyro  correlated 
drift  rate 

15 

bye 

y  component  of  gyro  correlated 
drift  rate 

16 

bzc 

z  component  of  gyro  correlated 
drift  rate 

17 

Vxc 

x  component  of  accel  and  velocity 
quantizer  correlated  noise 

18 

^yc 

y  component  of  accelerometer  and 
velocity  quantizer  correlated 
noise 

19 

z  component  of  accelerometer  and 
velocity  quantizer  correlated 
noise 

20 

fig* 

x  component  of  gravity  error 

21 

figy 

y  component  of  gravity  error 

22 

figz 

z  component  of  gravity  error 

23 

6hc 

barometer  correlated  bias  noise 

error 

24 

b*t 

x  component  of  gyro  trend 

25 

byt 

y  component  of  gyro  trend 

26 

bzc 

z  component  of  gyro  trend 

27 

v*t 

x  component  of  accel  trend 

28 

V 

y  component  of  accel  trend 

29 

z  component  of  accel  trend 
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Table  B.3  INS  Truth  Error  Kodel  Partition  6x3 


Definition 

x  component  of  gyro 
repeatability 

drift 

rate 

y  component  of  gyre 
repeatability 

drift 

rate 

z  component  of  gyro 
repeatability 

drift 

rate 

x  component  of  gyro 

scale 

factor 

error 

y  component  of  gyro 

scale 

factor 

error 

z  component  of  gyro 

scale 

factor 

error 

x  gyro 

misalignment 

about 

y 

y  gyro 

misalignment  about 

X 

z  gyro 

misalignment 

about 

X 

x  gyro 

misalignment 

about 

z 

y  gyro 

misalignment  about 

z 

z  gyro 

misalignment  about 

y 

x  gyro 

scale  factor 

non-linearity 

y  gyro 

scale  factor 

non-linearity 

z  gyro 

scale  factor 

non-linearity 

x  gyro 

scale  factor 

asymmetry 

error 

_ 

y  gyro 

scale  factor 

asymmetry 

error 

_ 

z  gyro 

scale  factor 

asymmetry 

error 

_ i 
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Table  B.4  INS  Truth  Error  Model  Partition  fix*, 


State 

Name 

Definition 

48 

x  component  of  accelerometer  bias 
repeatability 

49 

y  component  of  accelerometer  bias 
repeatability 

50 

?bz 

z  component  of  accelerometer  bias 
repeatability 

51 

x,y,z  components  of  accelerometer 

52 

and  velocity  quantizer  scale 

53 

factor  error 

54 

x,y,z  components  of  accelerometer 

55 

and  velocity  quantizer  scale 

56 

HfflH 

factor  asymmetry 

57 

coefficient  of  error  proportional 
to  square  of  measured  acceleration 

58 

fyy 

coefficient  of  error  proportional 
to  square  of  measured  acceleration 

59 

f2Z 

coefficient  of  error  proportional 
to  square  of  measured  acceleration 

60 

^xy 

coefficients  of  error  proportional 

61 

to  products  of  acceleration  along 

62 

fyr 

and  orthogonal  to  accelerometer 

63 

sensitive  axis 

64 

fzx 

65 

^zy 

66 

4l 

x  accel  misalignment  about  z 

67 

Pi 

y  accel  misalignment  about  z 

68 

43 

z  accel  misalignment  about  x 

69 

^3 

z  accel  misalignment  about  y 
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Table  B.5  INS  Truth  Error  Model  Partition  6xs 


Table  B.6  INS  Truth  Error  Model  Partition  £x6 


State 

Name 

Definition 

76 

F 

A  xyz 

x  gyro  compliance  terms 

77 

F 

rryy 

78 

F 

A  xyx 

79 

F 

A  xzy 

80 

F 

*xzz 

81 

F 

rxzx 

82 

F 

1  yzx 

y  gyro  compliance  terms 

83 

F 

ryzz 

84 

F 

ryzy 

85 

F 

x  yxz 

86 

F 

4  yxx 

87 

F 

88 

Fzxy 

z  gyro  compliance  terms 

89 

Fzx, 

90 

Fzxz 

91 

Fzyx 

92 

F 

r  zyy 

93 

F 

*  zyz 
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Appendix  C:  LN-94  Dynamic  and  Noise  Matrices 

This  appendix  provides  a  summary  of  the  content  of  the  dynamic 
matrix  and  the  noise  matrix  of  the  93 -state  LN-94  truth  model. 
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Figure  C.l  Elements  of  Dynamic  Sub-matrix  Fx 
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Figure  C . 10  Elements  of  Process  Noise  Matrix  Q22 
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Appendix  D:  Programming  Flew  Charts 


This  appendix  supplies  the  reader  with  program  flow  charts.  These 
charts  outline  the  program  flow  used  in  the  more  critical/complex 
functions  in  the  simulation.  For  specific  coding  techniques  the  reader 
should  refer  to  the  source  code. 

For  all  functions  except  MAIN,  there  are  two  functions  outlined  in 
the  upper  left  corner  of  the  first  page  of  a  flow  chart.  The  function 
to  the  far  left  is  the  calling  function  and  the  next  function  is  the  one 
being  called  and  displayed  as  a  flow  chart.  For  the  function  MAIN,  only 
the  function  MAIN  is  shown  at  the  upper  left  of  the  first  page  of  the 
flow  chart . 
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D.l  Function  MAIN 


Figure  D.l  Function  MAIN  Part  1 
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Figure  D.2  Function  MAIN  Part  2 
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Fa  I  se 


Figure  D.3  Function  MAIN  PART  3 
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D.2  Function  PROPAGATE 


Figure  D.5  Function  PROPAGATE 
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D.3  Function  INTEGRATE 
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To  Propagate 


Figure  D.8  Function  INTEGRATE  Part  3 
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Appendix  E:  Program  Functions 


Chapter  3  provides  the  global  overview  of  the  Simula  ion  program. 
In  this  appendix,  the  program  is  broken  down  into  functior  >  as  they 
relate  to  the  above  mentioned  modules  and  how  they  relate  to  other 
program  functions.  Refer  to  Table  E.l  and  Table  E.2  for  i  breakdown  of 
the  relationship  between  the  functions  and  the  modules.  Tie  invent  is 
not  to  provide  code  descriptions,  but  rather  to  describe  tie  general 
operation  of  the  function.  The  reader  is  referred  to  the  irogram  source 
code  for  code  level  descriptions. 

The  INS_LN94  executable  program  consists  of  the  INS_ ^N94  source 
code  which  contains  the  MAIN  function  and  is  linked  with  1  ive  ob-ject 
modules : 

1.  SETUP. OBJ 

2.  PROCESS. OBJ 

3.  MCDRVL . OBJ 

4 .  INSINT2 . OBJ 

5.  CLKT10 . OBJ 

There  are  35  functions  written  specifically  for  the  simulation  not 
including  the  MAIN.  In  addition  the  program  uses  10  commercially 
developed  functions.  Specific  discussion  of  the  commercially  developed 
functions  is  not  provided  other  than  to  indicate  where  they  are  used  and 
then  reference  the  applicable  documentation. 

For  simplicity,  the  functions  are  presented  in  alphabetical  order. 
The  function  is  identified  by  name  followed  by  the  name  of  the  host 
program  and  any  calling  function  names.  A  description  of  function 
operation  then  follows.  First,  a  look  at  functions  written  specifically 
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Table  E.l  Functions  Contained  in  INS  LN94.C 


INS_LN94.C 

Bitof f 

Biton 

Calc  Time  Tag 

Derivative 

Display_Lat_Long 

Extract 

Hundred  Ms 

Initialize 

INS_Error_Include 

Insert 

Integrate 

Keyboard 

Matrix  Ops 

Mode_Change_Time  r 

Model 

Msg_Equal 

Msg_Comd_Proc 

Noise 

Propagate 

Random_Number 

Trajectory 

Update 

Va 1 i d_M s g_Numb e r 

Write  Data 

Table  E.2  Functions  Contained  in  Object  Modules 


SETUP. C 

PROCESS  ,C 

CLKT10 . ASM 

INS_INT2 . ASM 

Introduction 

Process_CMD_l 

enbtim 

initl553 

Disp  ,y_Screen 

Process_CMD_2 

distim 

rem_hdlr 

Plot  Results 

Process  CMD  24 

test_1553 

for  the  simulation. 

E.l  Program  Specific  Functions 

E.1.1  Bitoff  Host  Program:  INS_LN94.C 

Calling  Function(s):  Process_CMD_l 

Calling  Convention:  Bitoff (unsigned  int.int) 

Function  Bitoff  is  used  to  set  specified  bits  in  a  word  to  zero. 
A  word  of  unsigned  int  is  passed  together  with  a  bit  mask  value  to  the 

£  2 


function.  The  word  value  is  AND'd  with  the  compliment  of  the  mask 
value,  and  the  result  is  returned  with  the  designated  bit  equal  to  zero. 
The  mask  values  are  defined  in  INSDEF.H  and  are  simply  hex  values  which 
highlight  the  bit  in  question.  For  example  the  masked  value  of  bit  one 
would  be  0x8000,  where  bit  one  is  the  most  significant  bit. 

E.1.2  Biton  Host  Program:  INS_LN94.C 

Calling  Function(s) :  Process_CMD_l 

Calling  Convention:  Biton(unsigned  int.int) 

Biton  works  in  a  similar  fashion  to  Bitoff  except  the  object  is  to 
set  the  masked  bit  to  a  value  of  one.  This  is  achieved  by  using  a 
bitwise  exclusive  OR  of  the  word  value  and  the  mask. 

E.1.3  Calc_Time  Tag  Host  Program:  INS_LN94.C 

Calling  Function(s):  Process_CMD_l 

Calling  Convention:  Calc_Time_Tag(unsigned  int) 

The  time  tag  is  defined  to  be  the  difference  between  the  process 
start  time,  and  the  time  the  sync  mode  command  is  received  from  the  bus. 
The  sync  word  is  passed  when  the  bus  interface  card  is  initialized  in 
the  function  Initialize.  The  units  of  the  time  tag  are  in  microseconds, 
with  the  least  significant  bit  or  truncation  point  at  50  microseconds. 

In  order  for  the  time  tag  to  fit  into  a  16  bit  entity,  the  calculations 
of  time  must  be  limited.  In  other  words,  the  intermediate  values  of 
time  must  be  limited  to  419  in  order  to  achieve  a  value  that  will  fit 
into  the  word  size  when  called  for. 

The  difference  between  process  time  and  sync  time  is  calculated 
and  from  this  value,  microsecond  units  are  derived,  and  the  value 
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truncated  to  the  nearest  50  microsecond.  Time  is  then  returned  to  the 
calling  function. 

E.1.4  Derivative  Host  program:  INS_LN94.C 

Calling  function(s):  Integrate 

Calling  Convention:  Derivative (double [] ) 

Derivative  is  called  by  Integrate  to  evaluate  the  system 
derivative  at  time  t.  The  system  derivative  is  defined  as  the  dynamic 
matrix  F  post  multiplied  by  the  state  vector.  To  evaluate  the 
derivative,  the  dynamic  matrix  and  the  state  vector  must  be  updated  to 
time  t. 

To  achieve  this,  the  state  vector  is  set  to  the  previous 
integration  solution,  and  then  the  function  Trajectory  is  called  to 
update  the  navigation  parameters.  Using  the  updated  parameters  Model  is 
called  to  evaluate  the  system  dynamic  matrix  at  time  t.  Derivative  then 
calls  Matrix  Ops  to  perform  the  matrix  multiplication.  The  new  system 
derivative  is  then  passed  back  to  Integrate  to  continue  propagation  of 
the  model. 

Note  that  the  stochastic  white  noise,  which  forms  a  part  of  the 
model  differential  equation,  is  dealt  with  in  another  function  and  noise 
is  injected  as  per  the  initial  conditions. 

E.1.5  Display_Lat_Long  Host  program:  INS_LN94.C 

Calling  function(s):  Process_CMD_l 

Process_CMD_2 

Update 

Calling  Convention: 

Display_Lat_Long(unsigned  int, unsigned  int , int , int , int) 


Display _Lat_Long  is  called  to  display  the  present  position  lat  and 
long  on  the  simulation  screen.  The  most  significant  and  least 
significant  words  of  either  lat  or  long  are  passed  to  the  function  along 
with  the  screen  position  in  row/column  format.  Additionally,  the  type 
LAT  or  LONG  is  passed  to  the  function. 

Using  a  shift  operation,  the  MSP  and  LSP  are  combined  into  one 
word.  The  value  is  checked  for  positive  or  negative  value  and  if 
negative,  a  2's  compliment  operation  is  performed  and  the  sign  value 
set.  The  value  is  then  scaled  according  to  FNU  85-1  and  the  degrees, 
minutes,  and  1000th  of  minutes  extracted.  The  direction  and  value  are 
then  displayed  to  the  screen  based  on  the  type  that  has  been  passed  to 
the  function.  Note  that  by  convention,  N  latitude  and  E  longitude  are 
positive . 

E.1.6  Display_Screen  Host  program:  SETUP. C 

Calling  function(s) :  Main 

Calling  Convention:  Display_Screen( ) 

This  function  makes  use  of  the  Essential  Software  C  Utility 
Library  functions  to  manipulate  screen  color,  cursor  position,  and 
formatted  output  to  set  the  computer  terminal  screen  for  use  of  the 
simulation.  The  function  also  calls  Write_Data  to  display  the  initial 
data  in  the  input  message. 

This  function  is  called  by  Main  at  the  beginning  of  the  program  to 
set  the  screen  and  then  all  other  screen  manipulations  are  done  by  other 
functions  as  required. 

E.1.7  distim  Host  program:  INS_INT2.ASM 

Calling  function(s):  Main 


Calling  Convention:  distimQ 

This  function  is  written  in  assembly  language  and  is  used  at  the 
end  of  the  program  to  disable  the  simulation  timer  and  reset  the 
interrupt  handler  to  operate  at  18.2  Hz. 

E.1.8  enbtim  Host  program:  1NS_INT2.ASM 

Calling  function(s):  Main 

Calling  Convention:  enbtim(int  far  *) 

This  function  sets  up  a  100  Hz  clock  for  timing  in  the  simulation. 
The  handler  for  DOS  interrupt  0  is  replaced  and  the  count  of  timer  0  is 
decreased  to  the  value  such  that  the  timer  interrupt  occurs  every  10 
msec.  The  original  interrupt  handler  is  called  at  18.2  Hz. 

This  function  also  stores  a  pointer  to  a  count  value,  which  the 
interrupt  handler  will  increment  every  time  it  is  called.  This  pointer 
is  monitored  to  calculate  the  simulation  time. 

E.1.9  Extract  Host  program:  INS_LN94.C 

Calling  function(s):  Insert 

Calling  Convention:  Extract (unsigned  int,int,int) 

A  word,  a  bit  start,  and  an  end  location  are  passed  to  the 

function.  Taking  advantage  of  bitwise  left  and  right  shifts,  the 

function  Extract  removes  bits  from  a  specified  word  starting  at  the 

designated  start  bit  to  the  designated  end  bit.  All  undesignated  bits 

are  shifted  out  of  the  word  and  the  remaining  value  is  passed  back  to 

the  calling  routine. 

E.1.10  Hundreds_Ms  Host  Program:  INS_LN94.C 

Calling  Function(s):  Main 

Calling  Convention:  Hundred__Ms ( ) 
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This  function  is  the  basis  for  the  timing  in  the  simulation.  The 
timer  is  set  to  interrupt  at  10  ms  intervals .  Hundred_Ms  tracks  the  10 
ms  count  and  when  100  ms  has  past,  the  function  will  return  TRUE. 
Otherwise  the  function  will  return  FALSE.  This  type  of  timing  sequence, 
in  essence,  means  that  the  Main  function  can  be  operated  based  on 
increments  of  100  ms . 

Since  the  maximum  10  ms  count  for  a  16  bit  unsigned  integer  is 
65535  the  maximum  simulation  time  would  be  slightly  greater  than  10 
minutes.  To  alleviate  this  restriction  Hundred_Ms  tracks  a  rollover 
count.  When  the  65535  limit  is  reached  a  count  of  65535  is  added  to  the 
time  for  computation.  This  technique  is  used  when  tracking  the 
difference  between  real  time  and  processing  time.  This  is  a  debugging 
technique  and  is  used  in  the  function  Update.  For  program  development 
this  time  is  shown  on  the  screen. 

E.1.11  initl553  Host  Program:  CLKT10.ASM 

Calling  Function(s) :  Initialize 

Calling  Convention:  initl553(int  far  *  it  far  *,int  far  *,int) 

This  function  initializes  the  Ballard  PC1553  interface  board  to  RT 
mode  and  sets  the  RT  address.  An  interrupt  handler  specifically  used 
for  the  Ballard  board  is  also  installed.  When  a  synchronize  mode  code 
is  received,  the  handler  will  set  a  variable  to  current  time  which  in 
turn  synchronizes  the  board  with  the  bus.  In  this  function,  this 
variable  is  initially  set  to  zero. 

E.1.12  Initialize  Host  Program:  INS_LN94.C 

Calling  Function(s):  Main 

Calling  Convention:  Initialize() 


E-7 


The  function,  as  the  name  implies,  is  called  by  Main  to  initialize 
program  variables.  It  also  initiates  the  simulation  timer  using  enbtim 
and  it  initializes  the  PC1553  interface  board  using  initl553.  The 
function  sets  the  initial  conditions  of  the  state  vector  and  sets  the 
operating  parameters  for  the  function  Integrate.  The  function  also 
initializes  the  1553  message  values  to  zero  and  opens  the  appropriate 
files  for  storage  of  data  as  requested  in  the  program  setup. 

E.1.13  INS_Error_Include  Host  Program:  INS_LN94.C 

Calling  Function(s) :  Main 

Calling  Convention:  INS_Error_Include( ) 

INS_Error_Include  correlates  true  trajectory  data  with  the  INS 
errors  that  are  propagated  in  the  simulation.  By  convention  INS- 
indicated  information  is  the  difference  between  true  trajectory  and  INS 
errors.  This  function  performs  the  operations  necessary  to  produce  INS- 
indicated  values.  It  also  makes  the  appropriate  transformations  to 
provide  information  in  the  proper  reference  frame.  It  is  also  the  point 
in  the  program  where  the  INS -indicated  values  or  the  error  state  values 
are  stored  to  file. 

Specifically,  the  function  calculates  the  errors  in  latitude, 
longitude,  wander  angle,  velocity,  acceleration,  pitch,  roll,  and 
platform  azimuth,  and  pitch,  roll,  and  yaw  rates.  These  calculation  are 
made  from  the  solution  vector  of  Integrate  and  transformed  into  the 
proper  reference  frame.  The  difference  calculation  is  made  between  the 
true  trajectory  and  INS  error  and  as  designated  by  the  user,  either  the 
error  states  or  the  whole  states  are  stored  in  files. 
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E.1.14  Insert  Host  Program:  INS_LN94.C 

Calling  Function(s):  Keyboard 

Calling  Convention:  Insert(int .unsigned  int,int,int) 

Function  Insert  pushes  a  designated  set  of  bits  or  value  into  an 
integer  word.  These  two  parameters,  as  well  as  the  start  and  end 
position  within  the  integer  word,  are  passed  to  the  function.  This 
function  utilizes  Extract  to  remove  start- 1  bits  from  the  word  and 
places  them  in  a  temporary  word.  The  value  or  designated  bits  are  then 
placed  in  the  temporary  word  and  Extract  is  used  to  place  the  end  bit+1 
bits  of  the  word  into  the  temporary  word.  The  new  word  is  passed  back 
to  the  calling  function. 

E.1.15  Integrate  Host  Program:  INS_LN94.C 

Calling  Function(s):  Propagate 

Calling  Convention:  Integrate (double) 

Integrate  is  the  most  complex  function  in  the  program  and  is  the 
function  responsible  for  propagating  the  system  model  and  providing  the 
resulting  INS  errors.  Integrate  finds  the  solution  to  the  system 
differential  equation  from  the  present  time  to  the  end  time  which  is 
passed  by  the  calling  function.  It  uses  a  fifth-order  Kutta-Merson 
routine  with  automatic  step  sizing  to  achieve  this  solution. 

Integrate  first  checks  to  ensure  variables  declared  in  Initialize 
are  within  the  function  limits.  If  this  is  not  the  case  the  function 
will  terminate  and  the  simulation  will  terminate.  The  parameters  that 
are  checked  are  start  time  versus  end  time;  time  cannot  propagate 
backwards.  The  maximum  step  size  is  checked  and  must  be  greater  than 
minimum  step  size,  and  the  control  flag  can  only  be  zero  or  one.  An 
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additional  parameter  that  is  provided  but  not  checked  is  the  error 
tolerance  used  in  the  error  checking  phase  of  the  program.  The  control 
flag  that  is  indicated  refers  to  check_step  which  when  set  will  control 
step  size  to  be  either  automatic  step  control  or  fixed  step. 

If  integration  time  (same  as  present  time)  is  very  close  to  end 
time  the  function  uses  the  Euler  method  of  integration  to  obtain  the 
solution.  Otherwise,  the  function  increases  the  step  size  and  uses  the 
Kutta-Merson  equations  to  find  the  solution.  If  integrate  time  is  not 
too  small  the  routine  moves  directly  to  the  Kutta-Merson  equations.  The 
Kutta-Merson  equations,  as  outlined  in  Chapter  2,  involve  calling 
Derivative  to  evaluate  the  system  derivative  for  time  t.  Time  is 
segmented  into  step  fractions  of  1/2,  1/3,  1/6,  and  1/8  in  addition  to 
time  zero. 

Once  the  solution  has  been  obtained,  Integrate  uses  an  error 
checking  routine  to  determine  whether  the  solution  is  viable.  The 
function  evaluates  the  difference  between  y <,  and  y5  and  computes  an 
error  estimate.  If  no  error  is  calculated,  the  function  will  increase 
step  size  for  the  next  iteration.  If  a  successful  step  with  some  error, 
the  function  evaluates  whether  an  increase  in  step  size  is  viable 
without  violating  error  tolerances.  If  an  unsuccessful  step  the 
function  will  reduce  the  step  size  and  try  re-evaluating.  If  under  the 
present  parameters  a  solution  can  not  be  achieved,  the  function  will 
terminate  and  return  a  value  of  the  component  which  can  not  be  evaluated 
within  parameters. 

After  a  successful  step  and  appropriate  step  size,  the  function 
evaluates  whether  at  the  end  time  or  at  step  time.  If  initial 
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conditions  dictate  noise  at  each  step  the  function  will  return  to 
Propagate  to  inject  noise  into  the  solution.  If  not  at  step  and  not  at 
end  time  the  function  will  continue  integration. 

In  all  cases  when  the  function  terminates,  the  status  of  the 
integration  is  returned  for  error  handling.  Refer  to  Section  3.3.1  for 
more  detail  on  this  function. 

E.1.16  Introduction  Host  Program:  SETUP. C 

Calling  Function(s):  Main 

Calling  Convention:  Introduction( ) 

This  function  interrogates  the  user  at  the  commencement  of  the 
program  asking  the  user  to  define  a  number  of  parameters.  It  opens  with 
an  overview  of  the  simulation  and  its  operation.  This  overview  may  be 
omitted  at  the  discretion  of  the  user.  The  user  is  asked  to  define  the 
type  of  trajectory  input  for  the  flight,  the  type  of  states  to  track  and 
store,  the  length  of  the  flight,  the  rate  of  data  collection,  and  then 
whether  to  carry  on  with  the  simulation  as  defined.  The  user  is  given 
the  opportunity  to  make  changes  to  the  above  parameters  before 
commencing  or  exiting  the  program  if  desired. 

The  function  uses  formatted  input  and  output  to  control  the 
question  and  answer  format  and  includes  fail-safe  techniques  if  the  user 
inputs  unexpected  information. 

E.1.17  Keyboard  Host  Program:  INS_LN94.C 

Calling  Function(s) :  Msg_Cmd_Proc 

Calling  Convention:  Keyboard( int) 

This  function  is  called  by  Msg_Cmd_Proc  to  accept  and  interpret 
keyboard  inputs.  It  accepts  all  valid  inputs  as  defined  by  the 
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simulation.  Specifically  it  accepts  the  ESC  key,  D01,  101,  124,  FI,  F2 , 
F3 ,  and  F4.  In  the  case  of  the  function  keys  Keyboard  sets  the 
operational  mode  of  the  INS,  uses  the  function  Insert  to  set  the  INS 
status  word,  and  in  the  case  of  NAV  mode  sets  the  start  time  for 
navigation  based  on  the  system  clock.  A  flag  is  also  set  to  allow  the 
program  to  enter  the  function  Mode_Change_Timer  when  an  operational  mode 
changes.  When  the  ESC  key  is  struck  the  exit  flag  is  set  and  on  return 
the  simulation  will  terminate. 

In  the  case  of  101  and  124  the  function  processes  each  character 
separately  and  completes  operation  based  on  a  CR.  Valid_Msg_Num  is 
utilized  to  check  the  validity  of  these  inputs.  If  valid  the  number  is 
accepted.  If  invalid  the  computer  bell  sounds  and  an  invalid  message  is 
printed  to  screen. 

An  integer  value  is  returned  from  this  function.  The  input  status 
(CR  or  no  CR) ,  message  id  (D  or  I),  and  the  message  number  are  OR'd 
together  and  this  integer  is  analyzed  by  Msg_Cmd_Proc  to  determine 
keyboard  inputs.  Note  that  single  key  inputs  such  as  ESC  are  not 
interpreted  directly  by  Msg_Cmd_Proc  but  rely  on  flag  setting  for  their 
interpretation. 

E.1.18  Matrix_Ops  Host  Program:  INS_LN94.C 

Calling  Function(s):  Derivative 

Noise 

Calling  Convention: 

Matrix_Ops (char .double [ ] { ] , int, double [ ] , int .double [ ] , int) 

Matrix_Ops  is  called  to  multiply  two  matrices  together. 

Permissible  matrices  are  a  two  dimensional  matrix  post  multiplied  by  a 
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one  dimension  vector.  The  operation  type  is  passed  to  the  function  and 
the  function  uses  a  switch  decision  loop  to  select  the  operation.  If  a 
request  other  than  is  requested  the  function  and  program  will 
terminate.  The  two  dimensional  matrix  and  its  column  dimension,  the 
single  dimension  vector  and  its  row  dimension,  and  the  resultant  matrix 
and  its  row  dimension  are  passed  to  the  routine.  The  function 
initializes  the  resultant  matrix  to  zero  and  then  does  a  row  by  column 
multiply  of  the  two  matrices. 

E.1.19  Mode_Change_Timer  Host  Program:  INS_LN94.C 

Calling  Function(s):  Msg_Cmd_Proc 

Calling  Convention:  Mode_Change_Timer ( ) 

The  simulation  does  not  perform  alignments  directly.  Instead  a 
timing  loop  is  initiated  to  simulate  alignment.  This  routine  is  entered 
from  Msg_Cmd_Proc  anytime  that  GC  align,  SH  align,  or  INFLIGHT  align  are 
called  for  from  the  keyboard.  The  function  uses  a  switch  decision  loop 
to  set  the  start  time  relative  to  simulation  time,  and  sets  the 
countdown  flag  which  indicates  countdown  in  progress.  It  also  changes 
the  mode  on  the  simulation  screen. 

E.1.20  Model  Host  Program:  INS_LN94.C 

Calling  Function(s):  Derivative 

Calling  Convention:  Model () 

This  function  is  called  by  Derivative  and  it  provides  an  updated 
version  of  the  system  dynamic  matrix  and  process  noise  matrix  for  use  in 
the  next  integration  step.  This  function  is  called  for  the  computation 
of  each  Kutta-Merson  equation. 
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The  function  first  equates  the  model  variables  with  the  latest 
trajectory  data,  and  then  computes  the  vertical  gains.  The  ECEF-to- 
true-frame  transformation  and  the  sensor- to-true-frame  transformations 
are  computed.  Elliptical  gravity,  craft  rate,  earth  rate,  platform 
angular  rate,  earth  radius,  and  linear  velocity  magnitude  are  also 
computed  based  on  the  trajectory  data.  Non-zero  components  of  the  23- 
state  dynamic  matrix  are  updated  as  well  as  the  components  of  the 
process  noise  matrix. 

E.1.21  Msg_Equal  Host  Program:  INS_LN94.C 

Calling  Function(s):  Process_CMD_2 

Update 

Calling  Convention:  Msg_Equal(unsigned[ ] .unsigned! ], int) 

This  function  is  called  to  help  reduce  the  computation  overhead  by 
not  computing  if  the  message  of  concern  has  not  changed.  The  function 
does  a  component -by-component  comparison  of  two  messages  or  arrays  and 
returns  a  FALSE  if  components  are  different,  else  a  TRUE  is  return.  The 
first  difference  that  is  encountered  will  return  a  FALSE,  which 
eliminates  the  need  of  checking  the  entire  array. 

E.1.22  Msg_Cmd_Proc  Host  Program:  INS_LN94.C 

Calling  Function(s):  Main 

Calling  Convention:  Msg_Cmd_Proc ( ) 

This  function  is  called  by  Main  to  handle  any  inputs  from  the 
keyboard.  It  processes  the  return  from  Keyboard,  and  if  a  CR  has  been 
input,  the  function  will  extract  the  ID  of  the  message  requested  and  its 
number.  Once  identified,  the  message  number  requested  is  updated  to  the 
screen.  In  addition,  if  the  request  is  for  the  input  message, 
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Write_Data  is  called  to  update  the  screen.  The  function  Update  handles 
all  output  messages  from  this  point. 

The  function  is  used  primarily  to  interpret  and  action  message 
changes.  However,  if  key  input  is  a  function  key  requesting  a  mode 
change  other  than  NAV,  the  function  will  call  Mode_Change_Timer  to  start 
the  alignment  timing  process. 

E.1.23  Noise  Host  Program:  INS_LN94.C 

Calling  Function(s) :  Propagate 

Calling  Convention:  NoiseQ 

This  function  is  called  to  provide  the  white  Guassian  noise  vector 
that  is  injected  into  the  system  model.  The  function  calls 
Random_Number  to  generate  a  vector  of  Guassian  random  numbers.  Since 
the  process  noise  matrix  is  diagonal,  it  is  not  necessary  to  make  any 
computations  such  as  Cholesky  square  root  and  since  G  is  identity,  the 
approximation  that  this  function  would  normally  implement,  Qd  -  GQGAt, 
now  becomes  Qd  -  QAt.  Delta  t  comes  from  Integrate  where  this  time 
represents  the  last  time  Qd  was  computed.  Utilizing  Matrix_Ops ,  the 
function  post  multiplies  Qd  by  the  Guassian  random  number  vector  and  the 
result  is  a  vector  with  statistics  N[0,Qd]. 

E.1.24  Plot_Results  Host  Program:  SETUP. C 

Calling  Function(s):  Main 

Calling  Convention:  Plot_Resul ts ( ) 

This  function  is  called  at  the  end  of  the  simulation  to  give  the 
user  the  opportunity  to  plot  any  data  that  may  have  been  collected 
during  the  simulation.  Th*1  plotting  routine,  EZPLOT,  is  invoked  when 
indicated  by  the  user.  If  the  user  chooses  to  plot  results  on  return 
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from  EZPLOT,  the  function  will  query  the  user  as  to  whether  to  restart 
the  simulation  or  exit  the  program.  If  plotting  is  not  desired,  the 
user  may  restart  the  simulation  or  exit  the  program. 

The  function  uses  Essential  Software  libraries  to  manipulate  the 
screen,  and  formatted  input/output  to  query  the  user. 

E.1.25  Process_CMD_l  Host  Program:  PROCESS. C 

Calling  Function(s) :  Main 

Calling  Convention:  Process_CMD_l() 

This  function  provides  the  MILSTD  1553B  formatted  data  that  is 
output  to  the  bus  controller.  It  provides  the  response  for  command  word 
#1  of  the  FNU  85-1  specification.  Refer  to  Appendix  A  for  the  words  and 
formats  that  are  transmitted  by  the  simulation. 

The  function  provides  processing  of  word  1  of  the  response  to 
command  word  #1,  which  is  the  INS  status  word.  If  the  mode  selected  is 
an  alignment  mode  the  function  sets  the  appropriate  bits  to  indicate  the 
mode.  In  addition,  it  monitors  the  progress  of  the  alignment  and 
displays  ATT  RDY,  DEG  RDY,  and  NAV  RDY  as  time  progresses. 

All  subsequent  words  are  processed  .<y  '  ng  the  INS  -  indicated 

solution  from  INS_Error_Include  according  to  :  .s  FNU  85-1  specification 
and  outputting  the  results  as  an  integer  in  hexadecimal  form. 

E.1.26  Process_CMD_2  Host  Program:  PROCESS. C 

Calling  Function(s) :  Main 

Calling  Convention:  Process_CMD_2 ( ) 

Process_CMD_2  is  called  by  Main  in  response  to  command  word  #2  of 
the  FNU  85-1  specification.  There  are  only  four  words,  msp  and  lsp  of 
present  position  latitude  and  longitude.  The  function  utilizes 


Msg_Equal  to  check  whether  the  position  has  changed  since  the  last 
process.  If  the  position  has  changed  the  words  in  CMD_1  and  CMD_2  are 
set  to  new  position.  Display_Lat_Long  and  Write_Data  are  called  to 
display  the  results  to  the  screen. 

E.1.27  Process_CMD_24  Host  Program:  PROCESS. C 

Calling  Function(s):  Main 

Calling  Convention:  Process_CMD_24( ) 

In  a  similar  fashion  to  Process_CMD_l ,  this  function  processes  the 
applicable  words  in  response  to  command  word  #24  of  the  FNU  85-1 
specification.  It  does  not  specifically  process  the  INS  status  word  but 
sets  the  status  word  for  this  function  equal  to  the  status  word  of  the 
Process_CMD_l . 

E.1.28  Propagate  Host  Program:  INS_LN94.C 

Calling  Function(s):  Main 

Calling  Convention:  Propagate (double) 

Propagation  is  the  coordinating  function  for  propagation  of  the 
system  model.  The  function  passes  end  time  to  and  calls  Integrate. 

After  Integrate  returns,  integration  status  is  checked  for  integration 
error.  If  there  is  an  error,  Propagate  terminates  the  program  and  an 
error  message  is  displayed  to  the  screen.  If  no  error,  and  if  at  end 
time  or  at  end  step,  the  function  computes  At  and  calls  Noise  for 
process  noise  injection  into  the  model.  After  noise  injection,  the 
state  vector  is  set  to  the  solution  vector  in  preparation  for  the  next 
integration  cycle.  This  process  continues  until  at  end  time,  at  which 
time  Propagate  returns  to  Main.  Refer  to  Section  3.3  for  a  more 
detailed  discussion  of  this  function. 
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E.1.29  Random_Number  Host  Program:  INS_LN94.C 

Calling  Function(s):  Noise 

Calling  Convention:  Random_Number (int .unsigned  int , int , double [] ) 

Random_Number  provides  a  vector  of  QNUM  random  numbers  to  the 
function  Noise.  It  is  seeded  by  system  time  at  simulation  start,  and  a 
vector  of  random  numbers  of  quantity  SIZE  is  generated.  A  random  number 
is  then  generated  to  select  one  number  from  this  vector.  The  function 
then  replaces  the  selected  number  with  another  random  number. 

Each  number  of  the  vector  passed  back  to  Noise  is  the  sum  of 
twelve  random  numbers  with  6.0  subtracted  from  that  sum.  This  process 
gives  a  vector  of  approximately  Guassian  numbers  with  statistics  of 
N  [  0 , 1  ]  . 

E.1.30  rem_hdlr  Host  Program:  CLKT10.ASM 

Calling  Function(s) :  Main 

Calling  Convention:  rem_hdlr() 

This  function  removes  the  interrupt  handler  installed  by  initl553 
and  replaces  it  with  the  interrupt  handler  present  before  initialization 
of  the  simulation. 

E.1.31  test_1553  Host  Program:  SETUP. C 

Calling  Function(s) :  main 

Calling  Convention:  test_1553() 

This  function  verifies  the  presence  of  a  Ballard  PC1553-2 
interface  board  in  the  host  computer.  It  writes  test  values  to  several 
locations  in  the  on-board  dual -port  memory.  It  then  reads  them  back  to 
verify  their  values.  If  the  values  are  not  consistent,  the  function 
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assumes  no  board  is  present.  If  no  board  is  present  the  function 
returns  FALSE. 

This  function  uses  various  library  routines  from  the  Ballard 
PC1553  interface  program.  Readers  are  referred  to  Ballard  PC1553  User's 
Manual  [5]  for  details  on  these  functions. 

E.1.32  Trajectory  Host  Program:  INS_LN94.C 

Calling  Function(s):  Derivative 

Calling  Convention:  TrajectoryQ 

Function  Trajectory  is  called  by  Derivative  and  provides  the 
updated  trajectory  data  so  that  the  system  model  can  be  updated  prior  to 
computing  its  derivative. 

For  the  static  navigation  case,  the  trajectory  data  is  unchanged 
from  the  start  to  the  end  of  the  navigation  period.  Therefore,  the  data 
is  coded  into  the  function  and  is  accessed  if  static  navigation  is 
requested.  If  a  flight  trajectory  is  requested,  function  Introduction 
opens  the  applicable  trajectory  data  file  for  reading  and  the  data  is 
read  from  the  file  by  Trajectory. 

E.1.33  Update  Host  Program:  INS_LN94.C 

Calling  function(s):  Main 

Calling  Convention:  Update () 

Update  is  used  to  keep  the  data  on  the  simulation  screen  current. 
It  updates  the  operational  mode  and  status  of  alignment;  ATT  RDY,  DEG 
RDY,  and  NAV  RDY.  It  also  uses  Display_Lat_Long  to  update  present 
position  lat  and  long  and  displays  simulation  time.  Msg_Equal  is  used 
to  minimize  the  computation  load  when  the  present  position  has  not 
change.  Update  then  uses  a  switch  decision  loop  to  determine  the  output 
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message  and  calls  Write_Data  to  keep  the  screen  data  of  the  message 
current . 

E.1.34  Valid_Msg_Num  Host  Program:  INS_LN94.C 

Calling  Function(s):  Keyboard 

Calling  Convention:  Valid_Msg_Num(int, int) 

Valid_Msg_Num  is  called  by  Keyboard  to  validate  keyboard  input 
when  the  user  tries  to  change  the  messages  on  the  simulation  screen. 

The  message  ID  and  the  message  number  are  passed  to  the  function.  If 
the  corresponding  ID  and  number  are  valid,  TRUE  is  returned  to  the 
calling  function,  else  FALSE  is  returned.  ID  and  number  must  coincide. 
In  other  words  a  user  can  not  input  D24  versus  124.  Each  component  of 
the  message  ID  and  number  is  confirmed  as  it  is  entered  so  the  program 
must  include  all  valid  numbers.  For  example,  in  124  the  ID  of  I  and  the 
number  2  and  24  must  be  valid  inputs. 

E.1.35  Write_Data  Host  Program:  INS_LN94.C 

Calling  Function(s):  DisplayScreen 

Initialize 

Process_CMD_2 

Update 

Calling  Convention:  Write_Data(unsigned  int [ ] , int , int) 

Write_Data  prints  the  contents  of  input/output  messages  in  the 
format  that  is  established  for  the  simulation  screen.  Only  the  modified 
words  are  updated. 

The  message  array,  the  length  of  the  array,  and  the  type  of 
message  (input/output)  are  passed  to  the  function.  The  type  designates 
the  cursor  position  when  preparing  to  update.  The  length  sets  the 
duration  of  the  update  cycle.  All  the  messages  vary  in  the  number  of 
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words  and  it  makes  no  sense  to  update  beyond  message  length.  The 
function  sets  the  position  of  the  cursor  and  then  outputs  a  hexadecimal 
number  to  the  appropriate  position  on  the  screen. 

E.2  Commercially  Developed  Functions 

The  following  is  a  summary  of  the  functions  utilized  from 
commercially  available  software  packages.  As  mentioned  previously, 
details  are  not  provided  for  these  functions  except  to  say  what  they  do 
and  indicate  where  to  get  more  detail. 

E.2.1  Essential  Software  C  Utility  Library 

This  library,  SLIBES.LIB,  is  linked  with  the  program  INS_LN94.C 
and  the  following  functions  were  utilized: 

1.  border- -set  screen  border  to  specified  color 

2.  clreol- -clear  to  end  of  current  line 

3.  clrscrn- -clear  current  screen 

4.  clscolor- -set  current  screen  to  specified  color 

5.  colptrc- -print  character  in  specified  color 

6.  colrptrf- -print  a  string  in  formatted  mode 

7.  colrprt.,- -print  a  string  in  specified  color 

8.  curlocat- - locate  the  cursor  by  row  and  column 

The  reader  is  referred  to  the  Essential  Software  C  utility  Library 
reference  manual  [11]. 

E.2. 2  Ballard  PC1553  Functions 

The  following  is  a  list  of  the  functions  utilized  from  the  Ballard 
Technology  PC1553  software: 


E-  21 


1.  readrtdwd- -reads  data  from  a  PC1553  sub-address 


2.  writertdwd- -writes  data  to  a  PC1553  sub-address 

3.  config- -configures  PC1553  by  writing  to  the  three  control 
registers 

The  reader  is  referred  to  the  Ballard  PC1553  Interface  User's  Manual 
[5]. 
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Appendix.  F:  Simulation  Operator's  Guide 


This  appendix  will  summarize  system/hardware  requirements  and  the 
procedural  steps  to  be  taken  when  operating  the  LN-94  INS  Simulation 
program.  The  intent  of  this  guide  is  not  to  outline  the  operation  of 
peripheral  devices  or  operating  systems.  It  is  assumed  the  user  has  a 
working  knowledge  of  an  IBM  compatible  personal  computer  and  the  DOS 
operating  system.  It  is  also  assumed  that  the  user  is  familiar  with  the 
operation  of  the  DTI  bus  control  software  and  the  physical  requirements 
of  the  MILSTD  1553  bus  connections.  Jt  is  suggested  that  the  user  also 
become  familiar  with  the  EZPLOT  plotting  routine  User's  Manual. 

This  guide  will  cover  the  computer  system  requirements,  hardware 
requirements,  and  the  required  configuration  of  the  bus  controller.  A 
step-by-step  setup  and  operational  procedure  of  the  simulation  is 
provided. 

F.l  System  Requirements  and  Hardware 

As  indicated  in  Chapter  3,  the  simulation  program  is  compiled  to 
take  advantage  of  a  80387  or  compatible  coprocessor.  In  addition,  the 
system  assumes  a  color  monitor  as  the  program  addresses  the  video  card 
for  screen  color  manipulation.  The  minimum  system  requirements  are,  a 
80386  computer  with  an  80387  coprocessor,  and  EGA/VGA  color  monitor.  To 
maintain  the  speed  of  the  program  the  processor  should  be  at  least  20Mhz 
and  the  system  should  have  a  hard  drive.  If  no  hard  drive  is  present 
and  a  floppy  drive  must  be  used,  then  the  user  should  ensure  that  data 
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storage  rates  are  slow  enough  so  as  not  to  impact  on  the  operation  of 
the  program. 

The  program  executable  is  approximately  50K  in  size,  and  as  long 
as  sufficient  RAM  is  available  for  the  executable  and  a  7K  stack,  the 
program  should  operate  without  problem.  For  storage  of  data,  a  typical 
file  in  ASCII  format,  at  a  collection  rate  of  10  seconds  for  three 
hours,  uses  approximately  70K  of  memory.  The  user  should  have  some  idea 
of  storage  requirements  prior  to  starting  the  simulation. 

The  simulation  requires  a  Ballard  PC1553-2  interface  board 
installed  on  the  host  computer  bus.  The  DTI  bus  controller  software  is 
to  be  installed  in  another  PC,  and  the  two  computers  interfaced  via  the 
Ballard  boards  and  the  appropriate  1553  bus  cabling  and  couplers.  If 
desired  a  printer  can  be  interfaced  to  the  program  host  computer  to  take 
advantage  of  the  plotting  routine  EZPLOT.  EZPLOT  only  has  drivers  for 
dot  matrix  printers  and  a  good  24-pin  dot  matrix  printer  should  be 
sufficient  for  quality  output.  If  a  printer  is  not  available,  EZPLOT 
outputs  to  the  screen  and  files  may  also  be  transported  to  another 
system  for  printing. 

F.2  Simulation  Setup 

Where  the  executable  is  located  on  disk  is  not  particularly 
important.  The  only  directory  requirement  is  that  the  program  must  be 
able  to  access  a  directory  path,  C:\UTILITY\EZPLOT,  to  store  data  files. 
The  plotting  routine,  EZPLOT.EXE,  as  well  as  the  two  trajectory  files, 
STRAIGHT. TRJ  and  FIGHTER. TRJ,  must  also  be  present  in  this  directory. 
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Boot  the  program  host  computer  and  go  to  the  simulation  directory. 
At  the  prompt  type  INS_LN94.  The  next  screen  the  user  sees  will  have 
the  program  title,  version  number,  and  programmer  name.  The  program 
will  prompt  the  user  by  the  question: 

DO  YOU  WISH  TO  READ  THE  PROGRAM  OVERVIEW?  Y/N 
The  user  enters  Y(y)  or  N(n).  It  should  be  noted  here  that  any  required 
inputs  to  screen  prompts  after  this  prompt  must  be  follow  by  a  CR.  If 
the  user  chooses  to  see  the  overview,  three  screens  of  literature  will 
be  displayed  giving  the  user  a  basic  idea  of  the  simulation  capabilities 
and  operating  procedures.  If  the  user  chooses  not  to  see  the  overview 
or  following  the  overview,  this  prompt  will  appear: 

SELECT  THE  TRAJECTORY  YOU  WISH  TO  USE: 

(1)  LITTON  FIGHTER  TRAJECTORY  (TWO  HOUR  SIMULATION) 

(2)  STRAIGHT  AND  LEVEL  TRAJECTORY  (MAX  6  HOURS) 

(3)  STATIC  NAVIGATION  FROM  AFIT  (NO  TIME  LIMIT) 

Selection  of  1  or  2  will  open  the  applicable  trajectory  file  for 
reading.  Selection  of  3  will  set  the  navigation  parameters  to  a 
stationary  condition.  The  next  prompt  will  be: 

DO  YOU  WISH  TO  TRACK  ERROR  STATES  OR  WHOLE  STATES: 

(1)  ERROR  STATES 

(2)  WHOLE  STATES 

(3)  NO  STATE  TRACKING 

Based  on  which  states  are  selected,  the  user  will  see  a  list  of  those 
states  which  will  be  tracked  and  stored.  If  no  states  are  cracked,  this 
will  be  indicted  on  the  screen  as  well.  Type  a  CR  and  the  next  prompt 
will  be: 

THE  LENGTH  OF  YOUR  NAVIGATION  SESSION  IN  MINUTES  IS: 

The  user  inputs  an  integer  representing  the  length  of  the  session  in 
minutes.  When  making  selection  the  user  should  remember  the  type  of 
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trajectory  that  was  selected  and  the  stipulated  length  of  the 
trajectory.  The  next  prompt  is: 

IF  YOU  SELECTED  STORAGE  OF  DATA,  ENTER  DATA  COLLECTION 

RATE  IN  SECONDS  ELSE  ENTER  ZERO: 

The  user  enters  an  integer  value  for  time  between  data  collection 
points . 

The  next  screen  will  give  the  user  the  opportunity  to  change  any 
of  the  previously  selected  parameters,  carry  on  with  the  simulation,  or 
exit  the  simulation. 

DO  YOU  WISH  TO  CHANGE  ANY  OF  THE  PARAMETERS  YOU  JUST  SELECTED: 

(1)  TRAJECTORY 

(2)  STATES 

(3)  SESSION  LENGTH 

(4)  TIME  BETWEEN  COLLECTION  POINTS 

(5)  NO  CHANGE 

(6)  EXIT  PROGRAM 

The  user  inputs  the  appropriate  request.  If  the  user  chooses  to 
change  a  parameter,  only  that  parameter  prompt  will  be  displayed  and 
then  returned  to  the  above  screen.  If  the  user  chooses  to  exit  the 
program  the  DOS  prompt  will  reappear.  To  carry  on  with  the  simulation 
enter  the  selection  for  NO  CHANGE. 

F.3  Simulation  Operation 

When  the  user  enters  the  simulation,  the  screen  will  change  to  the 
formatted  display  necessary  to  show  the  information  applicable  to  the 
simulation.  The  present  position  should  be  zero  latitude  and  longitude 
and  the  input  and  output  message  should  show  zeros.  At  this  point  the 
user  should  setup  the  1553  bus  before  carrying  on  with  any  simulation 
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The  user  should  establish  bus  control  with  the  DTI  bus  controller 

software,  Sceptre  [13].  Set  the  bus  controller  to  send  present  position 

latitude  and  longitude  to  the  simulation.  The  input  is  in  accordance 

with  command  word  #2  in  FNU  85-1  [3].  Refer  to  Table  A.l  for  details  of 

all  the  command  words  that  the  simulation  responses  to.  The  RT  address 

of  the  INS  is  05h.  The  process  is  master  to  remote,  sub-address  02h, 

receive,  and  four  data  words.  For  present  position  the  data  words  are: 

lC4Ah  msp  latitude 

lBOOh  lsp  latitude 

C435h  msp  longitude 

lFOOh  lsp  longitude 

These  represent  the  latitude  and  longitude  of  AFIT.  Transmit  the 
command  once,  and  the  simulation  screen  should  now  read  the  AFIT  present 
position. 

Return  to  the  simulation  and  select  one  of  the  alignment  modes  as 
per  the  list  presented  on  the  simulation  screen.  The  system  MUST  be 
aligned.  If  the  user  selects  NAV  before  alignment,  the  NAV  mode  will  be 
displayed  but  the  system  will  not  propagate.  After  alignment  (approx  10 
seconds),  the  user  may  enter  the  NAV  mode.  The  simulation  will  enter 
the  propagation  mode  and  the  input  and  output  messages  should  begin  to 
change . 

At  this  point,  the  user  may  wish  to  display  results  of  the 
simulation  on  the  1553  data  bus.  The  two  output  messages  that  the 
simulation  will  respond  to  are  in  response  to  command  word  #1  and 
command  word  #24  both  of  which  are  outlined  in  Appendix  A.  Using  the 
parameters  in  Table  A.l,  the  user  can  set  the  bus  controller  to  receive 
the  data  from  the  simulation. 
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As  the  navigation  proceeds  the  simulation  will  store  results  to 
the  EZPLOT  directory.  The  simulation  will  navigate  until  the  end  of  the 
navigation  session  or  until  the  user  manually  exits  the  program  using 
the  ESC  key.  When  the  navigation  session  is  terminated  at  the  end  of 
the  navigation  time  the  following  prompt  is  presented  to  the  user: 

YOUR  XX  MINUTE  NAVIGATION  SESSION  IS  COMPLETE 
or  if  the  simulation  is  terminated  by  the  user,  the  following  is 
presented: 

SIMULATION  HAS  BEEN  TERMINATED  PRIOR  TO  THE  END  OF  NAV  SESSION 
In  either  case,  the  system  will  wait  for  a  CR  and  then  display  the 
following: 

DO  YOU  WISH  TO  PLOT  ANY  OF  YOUR  RESULTS: 

(1)  YES 

(2)  NO  EXIT  PROGRAM 

(3)  NO  RESTART  SIMULATION 

If  the  user  selects  2  the  program  will  terminate  and  the  DOS  prompt  will 
reappear.  If  the  user  chooses  to  restart  the  simulation,  the  sequence 
in  Section  F.2  will  start  again.  If  plotting  is  selected  the  simulation 
will  turn  control  over  to  the  routine  EZPLOT.  The  user  should  refer  to 
the  user's  manual  of  EZPLOT  to  produce  the  plots  desired.  The  routine 
is  self-explanatory  and  should  not  present  any  difficulties.  For  using 
EZPLOT  the  file  names  used  in  the  simulation  are  listed  in  Table  F.l. 

Once  the  user  terminates  EZPLOT  control  is  returned  to  the 
simulation  and  the  following  is  displayed: 

DO  YOU  WISH  TO  START  THE  SIMULATION  AGAIN: 

(1)  YES 

(2)  NO  EXIT  PROGRAM 
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Table  F.l  File  Names  Used  by  EZPLOT 


Error  States 


6L 


61 


K 


File  Name 


del_lat . dat 


del_long . dat 


d_thetaZ . dat 


phi_X.dat 


phi_Y. dat 


phi_Z . dat 


vel  N.dat 


vel_E . dat 


vel_Z . dat 


delta_h . dat 


del  h  c.dat 


Whole  States 

File  Name 

longitude 

long . dat 

latitude 

lat . dat 

wander  angle 

wander . dat 

altitude 

alt . dat 

north  velocity 

vel_n. dat 

east  velocity 

vel_e . dat 

vertical 

velocity 

vel  v.dat 

north 

acceleration 

acc_n. dat 

east 

acceleration 

acc  e . dat 

vertical 

acceleration 

acc  v.dat 

roll 

roll . dat 

pitch 

pitch . dat 

platform 

azimuth 

azimuth . dat 

If  restart  is  selected,  the  sequence  as  described  in  Section  F.2  will 
start  again.  Exit  will  return  the  user  to  the  DOS  prompt. 

F .  4  Summary 

As  can  be  seen,  the  simulation  is  straight  forward  and  steps  the 
user  through  the  required  inputs.  By  reading  the  program  overview  at 
the  beginning  of  the  program  and  studying  the  steps  outlined  in  this 
guide,  the  user  should  have  no  problem  operating  the  simulation. 
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Sensitivities:  Mln/Meru  Drift  @  Latitude 


Appendix  G:  23-Stats  Mo  *el  Validation  Results 


This  appendix  provides  a  summary  of  the  plots  used  to  validate  the 
23-state  model. 
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Figure  G.l  Bntting  Results  for  North  Gyro  Drift 
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Figure  G.3  Britting  Results  for  Azimuth  Gyro  Drift 


G-  3 


0  6 

Figure  G.4 


12  18  24  30  36 

Time  (hours) 

6 L  for  North  Gyro  Drift 


0  6  12  18  24  30  36 

Time  (hours) 

Figure  G.5  61  for  North  Gyro  Drift 
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Figure  G.6  4>x  («e)  for  North  Gyro  Drift 
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Figure  G.7  4>y  («N)  for  North  Gyro  Drift 
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Figure  G.8  <f>z  (-€D)  for  North  Gyro  Drift 
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Figure  G.9  6L  for  East  Gyro  Drift 


C-6 


Time  (hours) 

Figure  G.10  51  for  East  Gyro  Drift 
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Figure  G  11  4>x  (tE)  for  East  Gyro  Drift 
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Figure  G.12  (f>y  (eN)  for  East  Gyro  Drift 
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Figure  G.13  <t>z  (-«D)  for  East  Gyro  Drift 
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Figure  G.16  <f>x  (eE)  for  Azimuth  Gyro  Drift 
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Figure  G.17  4>y  (eN)  for  Azimuth  Gyro  Drift 
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Figure  G.18 
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Sensitivities:  M1n/10  g  Bias 
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Figure  G.19  Britting  Results  for  North  Accelerometer  Bias 
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Figure  G.21  5L  for  North  Accelerometer  Bias 
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Figure  G.22  61  for  North  Accelerometer  Bias 


G- 14 


Figure  G.23  <t>x  (tE)  for  North  Accelerometer  Bi 


Figure  G.2U  <£y  («N)  for  Norm  Accelerometer  Bi 
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Figure  G.27  61  for  East  Accelerometer  Bias 
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Figure  G.28  4>*  («e)  f°r  East  Accelerometer  Bias 
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Figure  G.  29  <f>y  («N)  for  East  Accelerometer  Bias 
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Figure  G.30  4>z  (-«D)  for  East  Accelerometer  Bias 
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Appendix  H:  Simulation  Validation  Results  for  Static  Navigation 


This  appendix  is  a  summary  of  the  plots  that  were  generated  for 
the  static  navigation  validation.  All  plots  except  Figure  H.3, 

Figure  H.ll,  and  Figure  H.12  show  a  comparison  of  the  actual  INS  data 
and  the  data  generated  by  the  simulation.  Figure  H.3  shows  the  altitude 
results  from  the  simulation  The  altitude  for  the  INS  is  i.Ciu  because 
the  baro-altimeter  is  not  modelled  and  therefore  has  no  uncertainty. 
Figure  H.ll  and  Figure  H.12  display  plots  of  the  level  acceleration 
components  experienced  by  the  INS.  Plots  for  the  simulation  are  zero  as 
accelerometers  are  not  modelled  in  the  simulation. 
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Figure  H.l  Latitude  for  Simulation  and  INS-3  Hr  Stationary  Navigation 
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Figure  H.6 


Figure  H. 


Time  (minutes) 

Y  Velocity  for  Simulation  and  INS-3  Hr  Static  Navigation 
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7  Z  Velocity  for  Simulation  and  INS-3  Static  Navigation 
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Figure  H.10  Roll  for  Simulation  and  INS-3  Hr  Static  Navigation 


fN 

0) 


c 

o 

T) 

L_ 

Qj 

*Qj 

■vj 


X 


0 

-0.001 

-0.002 

-0.003 

-0.004 

0.005 

-0.006 

-0.007 

-0.008 


0  20  40  60  B0  100  120  140  160  180 


lime  (minutes) 


Figure  H.ll  X  Acceleration  for  INS-3  Hr  Static  Navigation 
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Appendix  I:  Simulation  Validation  Results  for  Straight - and-Level 
Tra jectory 


This  appendix  provides  a  summary  of  the  plotted  results  of  the 
straight  and  level  simulated  results.  Each  simulated  navigation 
parameter  is  plotted  against  the  true  trajectory.  Where  only  one  curve 
may  appear  on  the  plot,  there  are  two  and  the  error  is  so  insignif icant 
at  the  scale  resolution  of  the  plot  as  to  appear  to  be  zero.  Appendix  J 
summarizes  the  errors  between  the  simulation  and  the  true  trajectory. 
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Figure  1.1  Latitude  of  the  Simulated  and  True  Straight-and-Level 
T raj  ec  tor ies 


Figure  1.5  East  Velocity  of  the  Simulated  and  True  Straight-and-Level 
Traj  ectories 


Figure  1.6  Vertical  Velocity  of  the  Simulated  and  True  ! 
Level  Trajectories 


Figure  1.7  North  Acceleration  of  the  Simulated  and  True 
Level  Trajectories 
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Figure  1.8  East  Acceleration  of  the  Simulated  and  True  Straight-and- 
Level  Trajectories 


Figure  1.9  Vertical  Acceleration  of  the  Simulated  and  True  Straight-and 
Level  Trajectories 


Figure  I . 10  Wander  Angle  of  the  Simulated  and  True  Strai 
Traj  ectories 


Figure  I . 11  Roll  of  the  Simulated  and  True  Straight- 
Traj  ectories 
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Figure  1.12  Pitch  of  the  Simulated  and  True  Straight-and-Level 
Traj  ectories 


Figure  1.13  Platform  Azimuth  of  the  Simulated  and  True  Straight-and- 
Level  Trajectories 
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Appendix  J:  Error  Behavioi  of  Simulated  Straight -and -Level 
Trajectory 

This  appendix  provides  a  summary  of  the  error  behavior  of  the 
simulation  relative  to  a  true  straight-and-level  trajectory.  The 
results  of  the  simulation  are  differenced  with  the  true  trajectory  and 
the  results  are  plotted  for  analysis.  Appendix  I  provides  the  plots  of 
data  that  are  used  to  develop  these  error  results. 


Figure  J.l  Latitude  Error  in  the  Simulated  and  True  Straight-and-Level 
Traj  ector ies 
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Figure  J.2  Longitude  Error  in  the  Simulated  and  True  Straight-and-Level 
Traj  ectories 


Figure  J.3  Altitude  Error  in  the  Simulated  and  True  Straight-and-Level 
Traj  ectories 
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Figure  J.4  North  Velocity  Error  in  the  Simulated  and  True  Straight-and 
Level  Trajectories 


Figure  J.5  East  Velocity  Error  in  the  Simulated  and  True  Straight-and 
Level  Trajectories 


Figure  J.6  Vertical  Velocity  Error  in  the  Simulated  and  True  Straight 
and-Level  Trajectories 


Figure  J.7  North  Acceleration  Error  in  the  Simulated  and  True  Straight 
and-Level  Trajectories 
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Figure  J.8  East  Acceleration  Error  in  the  Simulated  and  True  Straight- 
and-Level  Trajectories 


Figure  J.9  Vertical  Acceleration  Error  in  the  Simulated  and  True 
Straight-and-Level  Trajectories 
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Figure  J . 10  Wander  Angle  Error  in  the  Simulated  and  True  Straight-and- 
Level  Trajectories 


Figure  J.ll  Roll  Error  in  the  Simulated  and  True  Straight-and-Level 
Traj  ectories 
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Figure  J . 12 
Trajectories 


Pitch  Error  in  the  Simulated  and  True  Straight-and-Level 


Figure  J.13  Platform  Azimuth  Error  in  the  Simulated  and  True  Straight- 
and-Level  Trajectories 
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